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.

ghmaps-with-traffic

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:

  1. wget http://download.geofabrik.de/europe/germany/nordrhein-westfalen/koeln-regbez-latest.osm.pbf
  2. ./td.sh datasource=koeln-regbez-latest.osm.pbf
  3. 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!

Integrate traffic data into your route planner

Update: there is a new blog post which shows integration of real time traffic info into GraphHopper from a real world example, including a simple UI based on HTML5 canvas.

There are several companies having its own traffic data e.g. those companies having an own fleet or fetching it from an external source. Often on the GraphHopper mailing list people ask how they can integrate this into GraphHopper and until now there was only descriptive information but no code example. This post will change this, where I’ve created a little demo project at github for this task. The demo is easy to use and provides a simple web service where you can POST your own JSON data influencing the routing. If you look at the Readme there are only three steps involved:

  • Start the route planner server with the area of your choice: ./td.sh datasource=your-osm-file.pbf
  • Visit http://localhost:8989 to try the routing
  • Now feed some data and try routing again:
    curl -H "Content-Type: application/json" --data @traffic.json http://localhost:8989/datafeed
    

The simulated traffic jam is marked red. The routing therefore tries to avoid it.

The necessary code is very minimal: just take the double value from JSON and use it as speed for the identified street:

edge.setFlags(carEncoder.setSpeed(edge.getFlags(), value));

A street is a so called ‘edge’ in GraphHopper, read more about internals e.g. in this presentation or in the official documentation. But how to find this GraphHopper edge from the coordinates (list of latitude,longitude)? Currently we just take the very first coordinate of the provided points list in the JSON:

Point point = entry.getPoints().get(0);
QueryResult qr = locationIndex.findClosest(point.lat, point.lon, EdgeFilter.ALL_EDGES);
EdgeIteratorState edge = graph.getEdgeProps(qr.getClosestEdge().getEdge(), Integer.MIN_VALUE);

But in reality this can get more complex and could be improved by using our map matching component. So we just hope here no other edge can be mixed up with a close but completely different edge. Such problems are possible if you get the data from external none-OpenStreetMap data sources or from vehicles on the road without a high precision coordinate information. Other important points on the TODO-list for this demo are that the routing should be locked while updating the graph and that stopping the server should flush the graph to make the newly received data persistent. Nevertheless this shows nicely how easy it is to feed GraphHopper with your own data where the possibilities are endlessly to e.g. block complete roads or prefer roads for routing and more. Let us know about your use case!

Releasing GraphHopper 0.4 and the GraphHopper Directions API

Today we are proud to release version 0.4 of our open source road routing engine GraphHopper. Try it out on GraphHopper Maps:

gh-0.4-screenshot

We’ve taken several months for that release, but not without a reason as the GraphHopper Directions API for business was in the works and is also released today! The Directions API is a hosted GraphHopper routing service for world wide usage, including up-to-date software and OpenStreetMap data. It also offers features not found in GraphHopper like address search (aka Geocoding) and the Route Matrix API. Sign up for free and give us feedback!

A big thanks for that 0.4 release goes to all of our contributors! This release also includes features sponsored by Geofabrik and Talent Systems – thanks a lot! Read here to see how to become a sponsor or how to benefit from our GraphHopper knowledge.

Now these are the highlights of GraphHopper 0.4:

Map Matching aka ‘Snap to Road’

There is now also a map matching component based on GraphHopper and released under the Apache License 2.0. This tool can be helpful if you need to track vehicles and import their GPX tracks which is helpful to “snap them to road” like e.g. allryder is using it to optimize urban transport data or attach instructions to GPX files automatically.

Read more about it here or at wikipedia.

Now have fun with GraphHopper and expect more exciting news!

GPSies.com using the GraphHopper Directions API

The founder Klaus of GPSies contacted me nearly 2 years ago when GraphHopper was still in its infancy. GPSies was using Google Maps in its path planning tool and as they are free to use and want to keep it they did not want to buy into the business version of Google Maps so they were seeking for alternatives. At that time GraphHopper was already fast but could not scale to world wide coverage and Klaus provided the necessary hardware to me for experimentation. After a few months of tweaking and further months of testing and minor bug fixing we were able together to replace Google Maps API with a self-hosted GraphHopper on a GPSies server.

Also other customer often requested a hosted version of GraphHopper and so the idea of the GraphHopper Directions API for business was born with several benefits over existing routing APIs like basing it on OpenStreetMap data, high privacy standards, a permissive usage policy and world wide coverage even for bike routing.

Today we proudly announce that GPSies switched to this architecture making routing for GPSies more efficient and more up-to-date and still keep the costs low. Especially the daily OpenStreetMap data updates and regular software updates will make GPSies keep on growing!

The Builder Pattern in Java With the Least Code Possible

Immutable objects are important to make your code more robust, especially in days of more parallelization. A builder pattern is used when some of the variables of an immutable class are required and some are optional. But this leads to a massive constructor explosion, at least in Java. Today I think I found an improved builder pattern which could be used with no attribute duplication in the builder class and no separate private constructor in the domain class.

Usual Constructors

Here is a normal immutable class with the various necessary constructors for only one optional field ‘age':

public class Person {
  private final String name; // required
  private final int age;     // optional

  public Person(String name, int age) {
     this.name = name;
     this.age = age;
  }
  public Person(String name) {
     this.name = name;
  }
  public Person(int age) {
     this.age = age;
  }

  public String getName() {
     return this.name;
  }
  public int getAge() {
     return age;
  }
}

Builder Pattern 1.0

The builder pattern removes the need of various constructor combinations:

public class Person {
  private final String name; // required
  private final int age;     // optional
  private Person(PersonBuilder pb) {
     this.age = pb.age;
     this.name = pb.name;
  }

  public String getName() {
     return this.name;
  }
  public int getAge() {
     return age;
  }
}

public class PersonBuilder {
  private String name;
  private int age;

  public PersonBuilder name(String name) {
     this.name = name;
     return this;
  }
  public PersonBuilder age(int age) {
     this.age = age;
     return this;
  }

  public Person create() {
     return new Person(this);
  }
}

The usage is:

Person p = new PersonBuilder().
   name("testing").
   age(20).
   create();

Builder Pattern 2.0

Now my builder pattern with less overhead. Of course in real world examples you won’t have only one optional field making the savings more obvious. The Builder Pattern 2.0 uses a static embedded subclass for the builder and still uses (package) protected fields. As you can see this solution is only ~5 lines more than the original immutable object without the constructors as it just moves the setters into a separate class:

public class Person {
  String name; // required
  int age;     // optional

  public String getName() {
     return this.name;
  }
  public int getAge() {
     return age;
  }

  public static class BEGIN extends Person {
    public BEGIN name(String name) {
      this.name = name;
      return this;
    }
    public BEGIN age(int age) {
      this.age = age;
      return this;
    }

    public Person END() {
      return this;
    }
  } // end of builder class
} // end of domain class

The usage is similar to the original builder pattern:

Person p = new Person.BEGIN().
   name("testing").
   age(20).
   END();

Keep in mind that this solution has the ‘drawback’ of no unnecessary object creation involved like builder pattern 1.0. And therefor the END method is not thread-safe unlike the create method. (You can fix that via this.clone() within END, not sure if you like that). Also I think for those cases you probably need more something like a factory. As noted in the comments the builder class START should be renamed to Builder and then even better create a public static method ala ‘Builder Start() { return new Builder(); }’ where you then can avoid the ‘new’ when using it.

Improvement: Builder Pattern 2.1

After the comments and having this implemented in production I observed drawbacks. E.g. that you don’t have to call the END method at all as the subclass is also accepted. And that you could theoretically just downcast a Person object to its builder and change the variables again. The simplest solution is to use composition instead of inheritance like we do with our AlgorithmOptions object at GraphHopper, this way we can also use private fields again.

Conclusion

This new builder pattern is suited if a method has several arguments with some of them optional. You can move these arguments into a separate class and use this pattern to avoid code duplication like I’ll probably do for some classes in GraphHopper. For everyone in love with magic (unlike me) they can also have a look into the project lombok as noted in the comments. Still the best thing would be to have something like this directly in Java and being able to write:

Person p = new Person(name="testing", age=20);