 I'm Peter, I'm one of the co-founders of the GraphHopper company, which mainly currently drives the development process of the GraphHopper routing engine. And I'm originally a physicist and all this started with a hobby. Back in the 2012, I fiddled around with routing algorithms and used OpenStreetMap as base to get routing across Germany, working on my weaker laptop. And this all then culminates in the GraphHopper routing engine, which is now able to process hundreds of millions of nodes on a bigger server in memory and serves routing responses within milliseconds. And yes, that's all the back end, basically 2012, seven years ago. And yeah, I think we can start now with the presentation. So, today I will talk about the GraphHopper routing engine and talk about the latest developments of the last year and also the future developments and new features in 2019 that we hopefully will add. And as I already said, I'm Peter, I'm a physicist and a programmer and problem solver and together people founded the company, the GraphHopper company and yeah, that's basically it. So, three founders are on top and what is the mission of our company just to clarify this. So, we want to build the routing software stack of the future with lots of open source software and utilizing open data like OpenStreetMap, which of course for our commercial services we currently have integrated also TomTom to offer other possibilities, but we always concentrate on this mission and to make this happening and also being sustainable and having a sustainable open source project we have to earn money. But this we will always invest in the open source community and open source software and also we heavily invest in OpenStreetMap community. We're one of the gold sponsors since a few weeks of OpenStreetMap foundation, which we are very proud of and recommend that companies do this. And yeah, that's all from advertising and I will go back to the GraphHopper Routing Engine. So, the GraphHopper Routing Engine as I said started from a hobby project seven years ago and it is a Java library and web service for routing. It does no maps, it does also no jail coding, but it has a web application demonstration application where we bundle this together so that you can see how the routing behaves. So, the routing just calculates the distance, the time and also the geometry and the turn instructions of the route. And it's a fast and memory efficient library that you can also use as a service. So, from other languages like Ruby, Python, PHP or whatever, it talks plain HTTP. It works with OpenStreetMap data but as I said also with others. And we have several algorithms implemented like Dijkstra, ASTAR and a few more sophisticated and faster algorithms like Landmarks, which is mainly ASTAR and Contraction Hierarchy CH. We talk from a higher perspective, Dijkstra and ASTAR are our flexible modes. Then there's the speed mode, which is Contraction Hierarchy and then there's the hybrid mode, which is still flexible but fast and this is a Landmark algorithm. And we support out of the box walking, car, bike, public transit and a few others like motorcycle and so on. And that's how it looks like. So, in the background there's a graph of the maps where you have jail coding bundled together with maps and routing. And in the foreground there's OpenStreetMap, where we are one of the two routing engines and yes, that's what it is. And now I can show you some demo. So, this is the route from the railway station to the university by food. And you can see the screen line, the geometry and also the turn instructions and the elevation data is all coming from the graph of a routing engine. But converting the address to coordinates and also the visualization of the map is done from external services. So, you can change the map to some other stuff. And yes, you can also see it's fast and continental size queries are possible within milliseconds. And yes, of course you can also do batch queries and stuff like this with a local installation. And yes, that's what I wanted to show. Now a bit more into the details. So, how are we doing algorithms with some kind of, or how the real world comes into the computer. So, from junctions the real world to nodes to graph over nodes. So, this is real world image. And as you can see the OpenStreetMap is quite similar. It maps or it creates the roads based on ways. For example, one way goes from here to here. It has several nodes, here's probably one, here's one and here. And it has some tags like the name but also like the direction, the one way tag. And other ways like this here need also some additional nodes to create the geometry. So, based on this you can say the ways consist of multiple nodes and tags. And the relations that for example for ferries based on multiple ways. And this is a really powerful way to express things but it's also really generic. So, for example, in OpenStreetMap you tag houses with ways. And you tag everything with ways like also roads but everything else also too. And graph upper, we just need edges and nodes. And for this we have to convert the OpenStreetMap data into our graph model into the mathematical graph. And we, for example, before this node was here and we do not need this node in the routing algorithm. But we still need this node in the geometry. So, we call the red dots the junction nodes or tower nodes. And all the other nodes are irrelevant for us except for the geometry. And all this we store in the edges, so the geometry, the other tags like names and distance of the edge. And then we have nodes, the junction nodes. And now even a bit low, even more low levels. So, we have two tables basically like nodes and edges. And then we have a linked list but this is not really important. But only as you can see we have a really simplistic storage layout that can be handled in memory but also on disk. And through memory mapping we are also able to run graphable routes on Android but also on iOS with some converter. And this is a really interesting way to make it portable. And this is, now we start a query somewhere in Berlin and then route to some other point in western of Berlin. And what you see are all edges and I think the green ones have a certain speed and the blue ones have a higher speed. And what is now blue is the shortest path or this dark blue color is shortest path tree. So the shortest path tree starts in Berlin and then is targeted towards the destination until it finds the destination. And then it can kind of go back from this node back to the root node and then prints the fastest path. It uses, under the hood it uses the Dijkstra algorithm with a goal directed heuristic which is A star. And it is unidirectional so it starts really to search until it finds node. We can also see that you can kind of do a reverse search from the destination back to the start. And then you have two searches at one time which is called bidirectional A star or Dijkstra. And this is something I've done for a different area. And what you can see here at the top is bidirectional A star which visits 25,000 nodes. The unidirectional A star visits 50,000 nodes so it's roughly half. So it's really important to understand that the performance or the speed of a routing algorithm is more or less directional proportional to the number of visited nodes. So bidirectional A star is roughly two times faster than a unidirectional A star. So we have now 25,000 visited nodes. The speed mode which is contraction hierarchy as I said before, visits even less nodes. It visits only 600 nodes. And the nodes are just a bit bigger plotted so that you can actually see them. So that's just an impression on how really the differences are here. Now I wanted to talk about the features we introduced in the last year and we'll also then talk about the newer features. So we improved the core of Graph Opera so that you're now able to show some path details. Like it's a bit crushed. The average speed can be returned for every segment of the path or the maximum speed or kind of any information that the graph stores. And as I will describe later we will improve this. It will be possible to store any information that OpenStreetMap offers into the graph and then you can print them for example in path details but also not even only this. Also you can customize routing based on those properties. And this is the foundation for this flexible, more flexible mode, how we call this. And also we updated the web framework used in Graph Opera. So before it was surflat based. Now it's using Drop Wizard and it's kind of improvement for developers only. But we think that it's a huge improvement and it was huge work. It's the same as with a better release management where we just can tag a commit and then it will be automatically released on Maven and have a zip file and so on. So one important thing was that we released the Isochrone API which was before closed source and it's now open source. And we can actually see this in action. So what is the Isochrone API? If you click somewhere and define start location then with the Isochrone API you get the reachable area from this start location for a certain vehicle mode like car in this case. So within 5 minutes you can reach all the places in the green polygon and the same for 10 minutes for the blue polygon. We also improved our public transit algorithm so that it handles better multiple GTFS feeds or it now supports to handle multiple GTFS feeds. And we have improved also the performance for the real time feature but in general for the whole public transit routing algorithm. The map matching is also faster so as you can see in this GIF it's snapping a list of GPS coordinates onto the road network and we can also see this in action. So what we are doing now, if I click the button the GPS track is sent to the service and we get then back the route that it snapped. So if I zoom in you can see the black is the GPS track so we have here two GPS points and the snapped route is perfectly aligned with the actual road geometry. But not only this, map matching allows you to return the turn instructions so if you have a hike trail or a hike event or whatever then you can send your route and attach turn instructions for others to use. But it can then also as I described the path details you can return every information that is stored in Graphhopper back like elevation, like average speed, maximum speed and so forth. So it's a really sophisticated and high, it's a really interesting thing for example if you have trucks and you want to monitor them if there are speed violations or if they are doing their work correctly then you can use this tool but also to do other interesting things. Now regarding the future work, so I told you that we have now improved the core to store properties and this work is continued so that we are, so that's possible to create kind of vehicle profiles on demand. So you can define a vehicle per request and change properties directly with a JSON or DUMMEL file or even in a scripting language. This is a highly experimental mode but I would like to present you this in the following demo application. So yeah the start and I can say disappearing somehow doesn't matter. So what we can do now is to avoid primary roads so completely restrict the access to this road and then you can see here this road flips using no primary roads now. Then I have a simplistic profile for wheelchair so we have the same no access property but now two steps so we don't want to go over our steps and we want to avoid cobblestone surface. So that looks a bit different and if we just remove one part then it will change here. There's a small step and this one will be avoided and the same with cobblestone we have the start of the route will be different if we avoid cobblestones. That's a cost score. It's currently kind of arbitrary where we have to, yeah it's relative. So you say this edge has a certain cost and the different edge, the specific picked edge like the primary road or whatever gets a 10 higher cost to traverse or to cross this road. But we will certainly limit those cost factors but currently we have no not enough experience. And now I'm also showing you this thing again that you can also of course exclude the bridges in case of some, I don't know, bridges are broken or to model what will happen if they break. And now I'm coming to show you the more interesting bits or I'm not sure if more is interesting but let's say you want to avoid. Maybe now I'm coming to this factor thing so now let's say we want to avoid the motorway. And one means there's no avoidance, two means we avoid it a bit but not everything as you can see and if we put a three here then we avoid everything. You can clearly see the impact on the travel time so one means 25 minutes, two is four minutes more and three is even 11 minutes more. And now this is relative simple with Jammel or simple to implement but it gets really interesting with scripting support. So we can have the same with scripting, avoid it and more or less completely block the motorways. Because why I think scripting support is important because you cannot really model everything with Jammel and I think it's not yet clear how we do this or everything. Scripting has other issues as well but I think it's really impressive to know that this is a Java code which is then compiled on the server side within I think one microsecond or even lower. And then really the performance of this generated Java bytecode is equal to native Java bytecode it's really impressive. You should check the compiler out it's a Nino compiler and then you can really, now what we are doing here is evaluate for I don't know one million nodes or the same things again. So this is also already highly optimized to make it fast but it's not yet in its end stages. No, no, this algorithm works with the flexible and the hybrid so with Dijkstra, ASTAR and landmarks. Contraction hierarchy is not flexible and there's no, there are papers that make it flexible but out of scope for us probably. But we will, we have implemented more sophisticated stuff so it's probably only a matter of time. And that's, so for the speed mode we have also now turn cost support. This was an issue which is heavily requested and this is now on master but it's still under heavy development because it's kind of really, really tricky and really even in the papers there seems to be some mistake so we have taken a different approach which is unique, kind of unique in the world that we have a node based graph not using a dual graph. But yeah I don't want to go into the details it's really sophisticated work that was done from Andreas Bart here. And we also, we all hopefully will have the alternative routes for the speed mode in graphable that makes you, yeah currently the alternative routes are really slow and you can't really create alternative routes for longer routes then I don't know 300, 400 kilometers which is really ugly and so we improve this, I hope to improve this with this and it's already working but now we have to improve the code and speed to make it production ready. Then we invested over the last few months into a navigation SDK. Mainly we, this is the work of Mapbox right, they have a really interesting navigation SDK the problem of the Mapbox SDK is there's a binary blob which is closed source since a few months which is really ugly. So we took the commit before this merge happened and then kind of also adapted the navigation SDK to our routing engine and make it everything working. So you can use a completely open source, a graphable routing service combined with a completely open source client-side, yeah Mapbox navigation SDK which we of course named graphable navigation SDK. And a demonstration application is also available on Play Store but it's not, I wouldn't say it's usable but it already demonstrates what it can. You have to turn for example GPS according it's on before you start the application to avoid issues and there are a couple of things but it's kind of, I tested in my car. And it's quite interesting and impressive that we can now have graphable for navigation for car navigation and also of course for any customized vehicle walking, biking and so on. So yeah that's it and as you can see there's lots of progress and yeah I think we are meeting at 7 with some OpenStreetMap guys after this. At 5 sorry 17, yeah sorry, at 5 here maybe. Thank you and yeah thanks for your attention.