WEBVTT 1 00:00:00.000 --> 00:00:51.000 Foreign. Welcome to the GeoMob podcast, where we discuss geo innovation in any and all forms, whether for fun or profit. Hi, everyone. Welcome back to another episode of the GeoMob podcast. Today we are once again turning our focus to the topic of routing. It is my pleasure to welcome as a guest Dennis Looksen, who is one of the makers of OSRM, which is a routing service focused on OpenStreetMap. It's been around for many years and the project seems to be reignited and is getting a new fresh push. So I thought it was appropriate that we bring Dennis in here and he gives us an update and tells us all about what's going on there. Dennis, welcome to the show. Wonderful to have you. 2 00:00:51.000 --> 00:00:52.000 Good to be here. 3 00:00:52.000 --> 00:01:04.000 Thank you. Why don't you start with you, introduce yourself, give us your background on geospatial, what got you into geospatial, and then we'll dive straight into osrm. All right. 4 00:01:04.000 --> 00:02:13.000 Hey, I'm the RSRM guy. That's my usual line. I came to OSM by somewhat accident. I started a career in academia working on routing algorithms. And one day there's this guy Frederick, he's well known at osm, calls me and asked me if I could present on the results that we had back then in academia, we all cared about numbers. So we had these very fascinating tables. If you're from the domain, if you're not, then it's just numbers to you. And I thought, okay, might be great if we had a demo. So I started working on a little demo that showed, okay, you can use OSM data for route planning. I was not the first. I think openroot service was there before, but the approach we took in academia was interesting. So we spent some time in pre processing the road network, getting additional data that you can use to accelerate queries afterwards. So I show up at this OpenStreetMap meetup 15 years ago, maybe. 5 00:02:13.000 --> 00:02:17.000 So what time are we talking about? We're talking around 2010 or so. 6 00:02:17.000 --> 00:02:19.000 We're talking 2010, 2011. 7 00:02:19.000 --> 00:02:20.000 Okay. 8 00:02:19.000 --> 00:02:40.000 So, you know, some of the origin history has been lost. So I don't actually recall when I first called the thing osrm. I don't recall when I did the first push to a public repository. I think there is an announcement email somewhere out there from 2011. 9 00:02:40.000 --> 00:02:54.000 I do remember that a big topic at this time was OpenStreetMap. Kind of moving from, hey, that's a kind of fun, weird hobby project to could this actually be something useful? And I guess this kind of falls into that movement. 10 00:02:54.000 --> 00:03:18.000 It does. It does. And the feedback we got was great. So the first time we showed routes, routes that you could drag across the map, halfway across the continent, that generated a lot of very good feedback and ignited the idea of having an open source project to make it available for everyone. 11 00:03:18.000 --> 00:03:31.000 And so in the beginning your involvement was it was kind of more of an academic kind of thought experiment of like, could this actually work or was this actually trying to build a consumer grade service? 12 00:03:31.000 --> 00:04:14.000 So somewhere in between, I'd say it started as a demo, a demo that I used to get funding from the scientific agencies. A demo that I used to show the OpenStreetMap community what could be done. A demo to show folks from industry what should be done. So we use that to great effect. And for each of these communities, I think what we achieved with OSRM was to bring them together. We had the OSM community, we had people from industry who started using it early on. And obviously in academia we used it as the showcase. 13 00:04:14.000 --> 00:04:50.000 Very nice. So maybe to set some context also for our listeners who are not deep in this topic, there are obviously many different routing services now, 15 years later that are based on, of course, on all kinds of other data, but also on OpenStreetMap. I can name several off the top of my head. What is the unique position of OSRM in that landscape? And maybe also what is just the current state of routing with Opus REMAP in general, in your opinion? 14 00:04:50.000 --> 00:07:29.000 All right, so OSRM's premise was to be extremely fast and to support routing at scale where you have a large fleet connecting to your backend services, asking for routes where you have latch demand that you can satisfy quickly. OSRM did this without compromising on the root quality itself. So even though we use additional pre processing, even though we use a trick here and there to speed things up, we always said, okay, we want to commit to solving the problem as the textbook says, right? We want to give guarantees that the root quality is not compromised. Where is the field today? Well, we've got a number of routing engines and we had routing engines before osrm. So we were not the first. A couple of folks to mention, I think openroot service was the first that I recall. I think there was PG routing on top of the postgres database. A couple of other folks came up afterwards. I think there's Graphhopper, Valhalla, and each of these make different trade offs. What sets OSRM apart is that we said, okay, we want to be a routing engine for the community, so we want to interpret the data as best as we can. According to what people say should be, should be done with. So we look at the OSM wiki, we follow that judiciously. We never compromise to fix data issues in code. We always push that upstream to say okay, once the, once the data becomes correct, the root will become correct. And you know, others in this space they traded the speed for, you know, let's say some of the versatility of changing, you know, how the routing should interpret the data more quickly. And I think that has a good application in urban planning. Right. And I think where proprietary services win is that they have live traffic, that they have maybe a more polished search for where origin and destination are. I think the OSM based engines when on cost they went on self hosting transparency of the data and sometimes even the raw routing throughput for high volume backends and 15 00:07:29.000 --> 00:07:41.000 again just to give the context to the listeners. So the project, it's open source software that anyone can host or is there a hosted version that I can use? What exactly are we talking about here? 16 00:07:41.000 --> 00:08:21.000 It's both. So first and foremost it's open source. You can download the code, you can compile it yourself, run it on your machine, pre process the data as you like and no one is telling you what to do with it. There is, you know, public service that is hosted by our friends from the German OpenStreetMap community that is also available on openstreetmap.org so if you computer route there, you select OSRM that goes to their backends using our software and there are a couple of commercial providers that you know, sell the privilege of requesting. Curious to you understood. 17 00:08:21.000 --> 00:08:31.000 And what exactly is your role currently? You're, you're the kind of lead developer on this and, and there are others contributing or how, what, what's the context? 18 00:08:31.000 --> 00:09:42.000 I would say I'm the benevolent dictator for life. So I started the thing, I was very active a couple of years ago, done, you know, maybe, maybe five to ten years ago I took a step back, I was thinking of, you know, handing it over and there was bunch of folks who worked on it who made great additions to the code and things quieted down maybe around the start of the pandemic, around that time frame and a year ago or so I thought okay, would be nice to bring it back up to shape. So it was dormant and I think what makes OSRM stand out it's this technical excellence. So it was very straightforward to revitalize the project and going to talk about this at state of the map, like OSRM is back, we have new features, we have New maintainers, we have people who are committing code to it. So the project looks very active. If you look at the past, let's say six months or so. 19 00:09:42.000 --> 00:09:44.000 Fantastic. Congratulations. 20 00:09:44.000 --> 00:09:46.000 Thank you. 21 00:09:46.000 --> 00:11:21.000 As someone who runs a geocoding service based on overstream maps, obviously there is one very common use case for geocoding is of course at the start of routing. But I'm intrigued by your comment that you push fixes to the data level rather than in the software. Because as someone trying to run a commercial service, obviously there are pragmatic considerations. Sometimes, sometimes the data can be a real mess. But also the community based model of the OpenStreetMap also means that sometimes fixing the data can be a challenge in. It can't. It's not always quick, particularly if you're not, you know, sometimes we have customers who complain about data problems in parts of the world where, you know, a. I don't really have a good, I don't have any experience with that part of the world. But also, you know, there is a local community that I'm definitely not a part of and so trying to engage with them of course can be a challenge. So tell us a little bit more about that and how you see things but also maybe about, and I mean one very good bit of news is in the last 15 years obviously the data has improved significantly and particularly around things like routing because now we have many automotive services that are now using the data, contributing back things like speed limits, turn restrictions, all these kinds of things. 22 00:11:21.000 --> 00:11:26.000 Yes, the data has grown in size tremendously over the past as well. 23 00:11:26.000 --> 00:11:39.000 Yeah, yeah. Give us your impressions there, how you see things have evolved and, but also this, I mean I would, I'm, I'm very impressed if you say you can always push back to the data level. I mean that's all right. Challenge. 24 00:11:39.000 --> 00:12:25.000 Yeah, let's, let's unpack that a bit. So you know, as a, as a side project it's, it's very easy to say, okay, we can make a principal stance and say, you know, we'll fix it in the data. If you, if you have a more pragmatic approach. Yes. Then you want to say, okay, there are a couple of trade offs that you can do to alleviate some of the issues with the data. But if you start fixing data issues in code by default it has this compounding effect that you have this bunch of one offs inside your code base and that has an impact on maintainability. 25 00:12:25.000 --> 00:12:28.000 Sure. And 26 00:12:28.000 --> 00:15:02.000 the main issue we have in software engineering is that when you have these compounding effects in a couple of years. You have no idea why that fix went in because this knowledge gets lost easily. And even if you document it, sometimes the next set of folks who come after you don't find these documents or they really have no idea why that issue really existed. It could be that the database or the underlying data moved on and it's hard to trace that back. In some sense, OSRM tries to be a bit more prudent than you would see that in industry. I think that's a good way because it allows us to go down this rabbit hole of trying to figure out issues where you don't have timelines, you don't have deadlines, you can go down, figure things out and come back out of it and say, okay, I have this thorough understanding of a particular issue now that doesn't need fixing here, it needs fixing there and we're good. From an engine perspective now on the data growth, that's a significant challenge. And I think everyone who's working with OpenStreetMap data is experiencing this in similar ways. The data is growing. The resources that you use today to make good use of the data, they don't suffice in a couple of years from now. So you always have to go with the growth. You have to sometimes engineer against the growth that you work on. Improvements that allow you to digest more or less or maybe, you know, use less processing resources to get to the same answer. So that's a constant challenge and I think that's what keeps working with OpenStreetMap data. Fascinating that it never stops changing, it never stops evolving. Look at the Vickies. People are still producing after 15 years, new proposal on how to, to tax stuff. And if you think about it, okay, within 15 years, shouldn't we have figured it all out? No, I think the world is full of, you know, more nuances than you know, you expect in the beginning. And this is what keeps the field interesting, this is what keeps, keeps it fascinating. And even after 15 years, still a joy to work with. 27 00:15:02.000 --> 00:16:04.000 I agree, agree. I mean I, you, you always learn new things and about different parts of the world and that is what keeps it fun. One thing, having been very active in OpenStreetMap for many years and working with it every day and we see the continual improvement of the data and the tools and all of this. Yet in my day to day life with friends and stuff, by far the dominant service remains Google. I would say to what extent, how much do you benchmark against Google's routing or let's say other proprietary routing and to what you Know, how do you see, how, how would, how would you say OpenStream map routing compares there? And to what extent are you gaining ideas from what they're doing? And, or maybe you see them taking ideas from, from the open source side. How do you see that dynamic? 28 00:16:04.000 --> 00:18:44.000 So I think there is, you know, anecdotal benchmarking. I, I'm not aware of, you know, an investigation of how this thing fares against the other in details. And I think both sides are, you know, not at a standstill, they're moving on. The routing space is surprisingly small. So I think, you know, every, every engineering group working on one particular side of this spectrum has good contact to the other one. So there is a bit of an exchange going on there. You know, I, I've been part of, and I had the privilege of being part of a, the group that rebuilt Apple Maps after its rocky launch. So that was very fascinating and interesting experience. To your question, how do these things compare against each other? Well, if you deduct for traffic data that we don't have in the OpenStreetMap world right away, at least not as accessible as the big players have in industry, I would assume. And, you know, it's more of a gut feeling because I don't know what the internals of everyone else is, that the underlying techniques are surprisingly similar, that the set of ideas that is being used is centering around this core, that road networks exhibit this hierarchy where you have important roads that are, you know, if your road is sufficiently long, almost always you will go over the highway. So there is, there's something about the highway that it carries a lot of traffic and that it, it shows up in routes between almost all points. And if you formalize this, and this is what OSRM is doing, you can extract this hierarchical information in a way that you don't necessarily have to rely on the formal classification, like what type of road is this? But you can find out. It's kind of a, you know, informal classification. How does it relate to its surrounding, how does it relate to the overall network? And that allows you to extract this hierarchy onto another level where you can use it to speed things up for fast queries or fast recomputation. And I would, I would assume that most players in the space are using techniques that exploit these properties. 29 00:18:44.000 --> 00:19:15.000 I see over the years at GeoMob, but particularly in, let's say, the last five years, we've had many talks from people working on different subsets of routing, be it bicycle routing, public transport routing, routing for the delivery use case. How do you See that, the differences there. Is it just kind of different weightings or something? Or do you think those require kind of bespoke tools? And how does OSRM handle this? 30 00:19:15.000 --> 00:20:44.000 Yeah, so transit routing is, I think, a very different beast. So the difference between roads and transit is that you don't have a timetable for your own car. Right. You don't have stops where you are with your own car. And from an algorithmic perspective, having this timetable, I know, has a combinatorial explosion of how, how much or how many possibilities you have to consider when computing a route. Right. So the, you know, the folks working on that developed a different set of approaches for transit routing, and I think that makes sense. There's great success in the way these things are handled, and it's a bit different than your car routing or your bike routing. Now, looking at car versus bike, I think you have very few types of car routings in the sense of, okay, am I really going to take a different route depending on the type of car that I drive? The answer is most probably no, unless you're going to the racetrack with a race car. But for biking, depending on the bike that you take, depending on the type of biker you are, are you commuting to work or are you having a workout? Are you on a speed bike versus, 31 00:20:44.000 --> 00:20:49.000 you know, the cargo bike, taking the kids to school? 32 00:20:49.000 --> 00:22:42.000 Cargo bike, yes. Very good example. So all of that makes a difference. All of that has an influence on your choice of pathways, of roads, of things you want to avoid, of things you're okay with, right? If you have a, if you know, if you have a race bike, you want to avoid gravel at all cost. If you have a mountain bike, you don't care so much. You're okay with that. So these preferences make bike routing very well. The set of preferences makes bike routing very interesting because there's not only one type of bike routing, but many. And finding a common core, finding what all of these things have in common, that's maybe a thing you have to figure out first when you do bike routing. And you probably have to settle on the 80% use case, like what, you know, what satisfies 80% of, of the bikers. That's probably what you want to aim for for bike routing. And sure, you know, for race bikes, for gravel bikes, for mountain bikes, for your cargo bikes, you can have bespoke things, but maybe it makes sense to give a first answer and have users adapt it depending on their particular choices or local knowledge, because sometimes you have information that you know that is very hard to put into map data. You know, you are on a cargo bike and you know you want to avoid a particular intersection because it takes long to cross it because it's inconvenient for particular reasons. The way the road is built, the way the traffic lights are built, maybe, maybe that's a thing that causes you to ignore, that that's very hard to put into data. And if it's not in the data, routing engines can hardly make sense of it. 33 00:22:42.000 --> 00:23:00.000 Yeah, I know we had a talk at GeoMob in Berlin last year about where the speaker was kind of begging everyone to start tagging the surface of the roads, whether it's cobblestones versus asphalt and things like that, because obviously that can have a big impact. 34 00:23:00.000 --> 00:23:33.000 Yes, the more data the better. And I remember that from a job a couple of years ago. I forgot this person's name, but what they said stuck with me. The remedy to bet data is more data. I think in the OpenStreetMap context, that makes a lot of sense. People should collect the most data they can because at some point someone will come around and make good use of it. 35 00:23:33.000 --> 00:24:00.000 Well, on that note, I know you are going to be speaking at State of the Map in Paris in a few weeks. Do you want to give us a little teaser of what your talk is going to be? But also more generally, what do you want to say to OpenStreetMap mappers around the world? What can they be doing to better help the routing use case? 36 00:24:00.000 --> 00:25:08.000 The topic of the talk for our State of the Map is OSRM is back. We're going to back this up with a couple of announcements that we will have on how we will support pedestrian routing in a better way across open areas, how we will support isochrone computation on how we improved the code base and the interpretation of the data in the past six months. And I think we'll have a very exciting release at State of the Map ahead of us. So people, people, I, I believe people will like what they're going to see. Now, how can people support the routing use case? Well, get involved. Get involved with collecting the data. Start using the tools, get involved with contributing back to your routing engine of choice. For me, that is osrm, start submitting patches and contributions and in our use case, everyone is welcome and we welcome everyone's contribution. 37 00:25:08.000 --> 00:25:49.000 Very nice. It's interesting because sometimes it comes up in the OpenStreetMap community that instead of everyone, all these scattered efforts with different routing engines or different editors or different geocoding services or different map rendering tools that maybe we should all just pick one and go with it and make it the perfect of tool. But I actually think quite the opposite. I think that we need the whole ecosystem of everyone trying out different ideas of mature tools versus kind of experiments versus and through doing that we really get the best of everything over time. Of course it's not always quick. 38 00:25:49.000 --> 00:26:47.000 Yeah, I agree. I think competition is good. I think there is a routing engine or two out there that started to come around because OSRM had shortcomings or would take some time to pre process the data and people want to have the first answer quicker after downloading the data and that is fair. And I think this competition is keeping us honest and it's collectively speaking helping us to push further. If there was no competition, if we would be having only one particular tool for a particular use case, I think we would be missing something. So I'm very happy about all the competition that there is for our srm. It helps us inform our opinion and I think this goes the other way around that what we do also informs the opinion of our others. 39 00:26:47.000 --> 00:27:06.000 Very nice. So I guess on that upbeat note, let's, we'll kind of wrap up our conversation here. Dennis, what is the, what is the best way for people to get in touch with you if they have questions and want to get involved? Obviously we'll have some links in the show notes, but how should they take up contact? 40 00:27:06.000 --> 00:27:57.000 Yeah, so we're easy to reach, just Google followers rm and what you will find is our GitHub page, our Discord page, the chats that we have, the mailing lists. Most of the conversation today happens on Discord as well as on GitHub. That's where the computer contributors get together. And you know, I'm also reachable on LinkedIn so if people are looking for myself, they can find me there. We cut back on the social media a bit and I think this helped us focus on what actually matters and that is improving our routing engine and making sure that we deliver best in class experience when it comes to routing on OpenStreetMap data. 41 00:27:57.000 --> 00:28:23.000 Very nice. Well, congratulations to you, congratulations to all the contributors of OSRM for the project and welcome back. I know you haven't really been gone, you've been working on it, but it's exciting and I wish you a successful talk in Paris and I hope you reignite the spark in the community. So very nice. 42 00:28:23.000 --> 00:28:27.000 Thank you so much Ed. It's great to be back. 43 00:28:27.000 --> 00:28:31.000 Great, well let's wrap it up there then. Thanks for coming on the show, Dennis. 44 00:28:31.000 --> 00:28:35.000 Thank you 45 00:28:35.000 --> 00:29:09.000 thanks for joining us today on the GeoMob podcast. We hope you enjoyed the discussion. You can get the show notes over on the website, which is@thegeomob.com and while you're there, you can sign up for our monthly newsletter and find links to our accounts on Mastodon and LinkedIn. So you can stay up to date on all our upcoming events. We hope to see you at an event soon.