[00:00.000 --> 00:12.800] So, we start with three presentations, it's like a routing topic now from three different [00:12.800 --> 00:18.400] countries, we present you three different routing topics and I think all of us can relate [00:18.400 --> 00:24.080] to this topic at least as a customer and it's a pleasure to me to introduce Felix Gündling [00:24.080 --> 00:32.120] from Germany, he's introducing MOTIS as a door-to-door platform, what is going open [00:32.120 --> 00:38.680] source in 2020 and is already used by some companies for internal use cases and we are [00:38.680 --> 00:51.560] really pleased to hear what is MOTIS about. [00:51.560 --> 01:03.080] Thank you very much for introducing me, today I will talk about MOTIS project and so this [01:03.080 --> 01:09.640] is a very rough overview of MOTIS, I think I could talk hours about all the details but [01:09.640 --> 01:16.800] I try to make it short so to give an overview MOTIS is a mobility platform and it's modular [01:16.800 --> 01:22.640] so it has different modules for different purposes and you can mix and match all those [01:22.640 --> 01:29.480] modules for your use case but I think the main functionality of MOTIS is the door-to-door [01:29.480 --> 01:36.000] routing that involves all kinds of means of transportation. [01:36.000 --> 01:44.600] So this includes walking, trains, buses, flights or we have also experiments for ride sharing [01:44.600 --> 01:50.160] or on-demand integration, basically you name it, everything that brings you from A to B [01:50.160 --> 01:58.480] we can use it in MOTIS and to display the data like the connections we have also our [01:58.480 --> 02:04.640] own tile server so this is a very easy way to get your own tile server also if you are [02:04.640 --> 02:11.200] only interested in displaying connections or anything on the map and of course for the [02:11.200 --> 02:18.440] user to be able to enter their wish from where to where they want to go we can also autocomplete [02:18.440 --> 02:22.960] places and yeah it's open source. [02:22.960 --> 02:29.680] So a short history of MOTIS or a long history basically it started in 1996 when I was still [02:29.680 --> 02:37.040] in primary school and so I cannot tell you much about it but there were first experiments [02:37.040 --> 02:46.800] about timetable data models and also the first routing algorithms and in 2003 it became multi-criteria [02:46.800 --> 02:55.880] optimization algorithm and I will go into some details later in 2007 MOTIS was the first [02:55.880 --> 03:00.560] platform that already had real-time information and could find connections on this real-time [03:00.560 --> 03:06.240] information so basically if you had delays or cancellations or reroutings this was the [03:06.240 --> 03:14.640] first time that you could actually find alternatives that would work in real-time. [03:14.640 --> 03:22.880] In 2013 we started to work on the door-to-door routing and this is actually my main topic [03:22.880 --> 03:32.080] and there we have all kinds of special topics for example we had one guy working on reliability [03:32.080 --> 03:37.640] so to find especially reliable connections where you also consider the reliability of [03:37.640 --> 03:42.400] all the alternatives so if something breaks you find still an alternative that brings [03:42.400 --> 03:49.600] you to your destination before your deadline with a high percentage of reliability considering [03:49.600 --> 03:54.120] the data from the past regarding the delays. [03:54.120 --> 03:59.760] Currently one of our main topics is accessibility so we are aiming at finding connections not [03:59.760 --> 04:07.320] just for everybody who has no problems but for all people who have some disability and [04:07.320 --> 04:12.520] there are different profiles so this is a profile-based approach where you can give [04:12.520 --> 04:19.040] us the information about profile you have and MOTIS will find those connections regarding [04:19.040 --> 04:20.360] your profile. [04:20.360 --> 04:28.960] Additionally we are working on park and ride so if you don't want to just go from A to [04:28.960 --> 04:33.880] B but you want to go back and you have your car parked somewhere then you have dependencies [04:33.880 --> 04:40.120] between the outward trip and the return trip and you cannot plan those journeys easily [04:40.120 --> 04:46.400] with the algorithms that are available on the market because your outward trip and return [04:46.400 --> 04:52.600] trip would not necessarily contain the same parking place and MOTIS has an integrated [04:52.600 --> 04:57.600] optimization algorithm that optimizes the park and ride problem. [04:57.600 --> 05:05.000] Additionally we are working on integrating ride hailing and ride sharing so different [05:05.000 --> 05:11.360] kinds of mobility and we are mixing everything together and find optimal journeys from door [05:11.360 --> 05:15.280] to door using all of them. [05:15.280 --> 05:21.800] Basically in 2020 then came the time that we made it open source and the open source [05:21.800 --> 05:27.480] version doesn't contain all of our experiments because those experiments were like branched [05:27.480 --> 05:32.920] from the master branch and it's a lot of work to combine everything into one version [05:32.920 --> 05:39.240] and so currently we are working on making all those experiments also open source and [05:39.240 --> 05:47.720] to maintain them all in one consistent version where you can also mix all the features together. [05:47.720 --> 05:53.560] Since we made it open source we gained some interest also by other companies so our primary [05:53.560 --> 06:00.840] partner for all the time since 1996 was Deutsche Bahn, German Railway and since then since [06:00.840 --> 06:06.480] we made it open source also other companies became interested in using our software and [06:06.480 --> 06:17.400] some of them are already using MOTIS in production and that's the path and we will be like I'm [06:17.400 --> 06:24.720] happy to see even more usage of MOTIS in production. [06:24.720 --> 06:28.920] You might also be interested who is developing MOTIS, this is mainly the Technical University [06:28.920 --> 06:40.440] of Darmstadt and currently we have three researchers that are working on MOTIS that's me and to [06:40.440 --> 06:47.080] others and all the time we have a lot of students doing their thesis projects or lab topics [06:47.080 --> 06:54.120] or some paid students working on MOTIS so we have a lot of churn in developers it's [06:54.120 --> 07:01.360] not always the same team but that's the research topic and as mentioned before I want to talk [07:01.360 --> 07:08.280] a little bit about multi-criteria optimization because that's one the main difference between [07:08.280 --> 07:15.040] rooting on the street and rooting with all kinds of transportation means is that usually [07:15.040 --> 07:20.320] it's not sufficient to only optimize the travel time or the distance traveled but you [07:20.320 --> 07:27.720] have also other criteria like the number of transfers or some people like want to travel [07:27.720 --> 07:34.760] cheap or some want to travel sustainable so they don't want to have a lot of CO2 produced [07:34.760 --> 07:41.520] and so there are different criteria and we actually don't know exactly what mix of criteria [07:41.520 --> 07:50.400] the user currently using our software has so this is a difficult problem to solve and [07:50.400 --> 07:55.680] since we don't know this we give them all the optimal solutions regarding the criteria [07:55.680 --> 08:04.200] so basically we do a multi-criteria optimization and find the Pareto set of all optimal solutions [08:04.200 --> 08:13.640] that form an optimal trade-off and currently the main version of MOTIS has the three criteria [08:13.640 --> 08:19.080] departure time arrival time and number of transfers so it's better to depart later arrive [08:19.080 --> 08:25.320] earlier and we want also to have the number of transfers so in this example we have three [08:25.320 --> 08:35.960] connections and basically for example the nine o'clock connection that goes to 10.15 [08:35.960 --> 08:41.840] has two transfers so it but it takes longer and then nine to ten connection has three [08:41.840 --> 08:46.720] transfers but it's faster and since we don't know exactly who wants which connection we [08:46.720 --> 08:53.280] just show all of the connections so if we look at those criteria we would show the optimal [08:53.280 --> 09:02.400] connection for like the fastest connection for all number of transfers and yeah basically [09:02.400 --> 09:10.000] the approach can be adapted to optimize a set of all criteria that you can basically measure [09:10.000 --> 09:18.080] in math that you can count in a way so how does it work how do we make the door-to-door [09:18.080 --> 09:26.440] routing basically we have two steps one step is to compute the connections from the actual [09:26.440 --> 09:33.120] address where you start to all the stations of the that could connect you to public transport [09:33.120 --> 09:38.840] or in general timetable based means of transportation and we do the same on the destination side [09:38.840 --> 09:46.720] so we look at all the stations in proximity to the destination and we route basically [09:46.720 --> 09:55.760] from all those to the destination so we convert these options to go from the start to the [09:55.760 --> 10:02.520] station or from the destination to the destination to a set of edges and all these edges are [10:02.520 --> 10:08.520] then inserted temporarily in the data model of our main routing algorithm and for those [10:08.520 --> 10:15.400] main routing algorithms we support a variety of routing algorithms that optimize the connection [10:15.400 --> 10:21.520] the overall door-to-door connection so here we have for example the Raptor routing algorithm [10:21.520 --> 10:30.600] the trip-based routing algorithm or just a graph-based solution that is the extra-based [10:30.600 --> 10:39.200] and yeah so this is the optimization approach and it's a nice approach because it guarantees [10:39.200 --> 10:47.160] optimality and all those algorithms that are named are producing exactly the same results [10:47.160 --> 10:53.600] so this is basically our quality assurance that we want to make sure that all the algorithms [10:53.600 --> 10:57.520] that we have in our system produce exactly the same results that because they have the [10:57.520 --> 11:06.480] same definition we are like the department at technical university of townstatt that [11:06.480 --> 11:12.360] is producing or working a motorist is the algorithm department so our focus is basically [11:12.360 --> 11:18.240] on the algorithms but to be able to show the platform we have some front ends and we have [11:18.240 --> 11:25.280] an Android app we can show the timetable data on a live map and we have also an interface [11:25.280 --> 11:31.640] to search the connections and actually use the routing but those front ends are currently [11:31.640 --> 11:37.960] not capable to display all the functionality that the back end has so our focus is more [11:37.960 --> 11:45.640] on the back end and algorithms and I want to talk a little bit also about our roadmap [11:45.640 --> 11:55.080] so we are currently working on making those accessible door-to-door routings possible [11:55.080 --> 12:05.720] that's our main focus and therefore we are working on a new data model that is also capable [12:05.720 --> 12:17.280] of displaying or saving the timetable data in a compressed way so we don't have one [12:17.280 --> 12:23.720] object per connection but if a connection takes place on several days of the year and [12:23.720 --> 12:31.640] at the same time then we store the connection with the bit field that has a one if the connection [12:31.640 --> 12:39.800] takes place at that day and zero if not so this is a very efficient way of encoding the [12:39.800 --> 12:49.680] timetable so additionally we use for the street routing currently OSRM which is very intense [12:49.680 --> 12:56.040] in memory usage but there are alternatives and we are trying to integrate those two and [12:56.040 --> 13:00.880] of course as I said before we are working on bringing more and more of the research [13:00.880 --> 13:07.720] functionality that we have in different branches into the mainline motors so you can use them [13:07.720 --> 13:15.600] together and like bring the research into production yeah that's that's it about motors [13:15.600 --> 13:21.280] if there are questions I'm happy to answer or I could also like make a short demo because [13:21.280 --> 13:26.040] yeah so maybe questions first yeah [13:26.040 --> 13:36.520] This is to the next question, how do you decide on that? [13:36.520 --> 13:44.480] Currently we ask the user to give us the maximum time he would like to use for the first and [13:44.480 --> 13:51.320] last part of the journey for each means of transport so he would say I would like to [13:51.320 --> 13:56.200] travel maximum 20 minutes by car and that's basically our limit but of course this is [13:56.200 --> 14:00.000] only one way to do it and this is the backend functionality so if you would use this as [14:00.000 --> 14:06.120] a user in an app or on a website this doesn't need to be the way that the user interacts [14:06.120 --> 14:27.360] with the system I didn't look like I think their algorithm [14:27.360 --> 14:33.120] is not open source so I couldn't look into the very details but from what I've seen [14:33.120 --> 14:39.040] I think they are not doing their computations in one data model like we have basically then [14:39.040 --> 14:43.800] one data model where we do the overall optimization so we can guarantee the optimality on this [14:43.800 --> 14:49.080] data model because it's all included and from what I've seen what they do is that they have [14:49.080 --> 14:56.480] different routings and they try to combine the routing results in a post-processing step [14:56.480 --> 15:02.000] and I think this doesn't guarantee optimality but produces probably reasonable results for [15:02.000 --> 15:03.000] the end user. [15:03.000 --> 15:04.000] Thank you. [15:04.000 --> 15:12.000] How are you able to take in account the life like a traffic jam or like how do you... [15:12.000 --> 15:24.040] Yeah we have the option to use GTFS RT real time data for the timetable based means of [15:24.040 --> 15:30.560] transportation and currently we are using for the street routing also our arm or like [15:30.560 --> 15:37.560] we are planning to support Valhalla and those can or cannot depending on how you configure [15:37.560 --> 15:43.000] them so this is not our main focus but this basically depends on which algorithm you use [15:43.000 --> 16:12.960] to compute those first and last edges. [16:12.960 --> 16:20.400] So basically what we do is that you download all the data put it all in one folder on your [16:20.400 --> 16:28.480] server and give that folder to Motors so it has all the timetables as in the GTFS format [16:28.480 --> 16:34.920] or a half horse rodent format and you give it the open street map data and you can give [16:34.920 --> 16:42.200] it for the real time data API endpoints where Motors will pull regularly like in a one minute [16:42.200 --> 16:48.680] or 30 second interval the real time data and so this is basically how all the data comes [16:48.680 --> 16:55.000] together in one data model so Motors loads all the static timetable data at boot time [16:55.000 --> 17:02.400] and possibly does some preprocessing on it and then in the real time it pulls real time [17:02.400 --> 17:06.240] data from the sources that you have configured it to pull. [17:06.240 --> 17:16.400] Trans model? Sorry I didn't. I haven't heard about it. [17:16.400 --> 17:21.560] Okay so CN standards concerning data modeling for multimodal transport this is why I thought [17:21.560 --> 17:24.360] that might be an association but it's independent. [17:24.360 --> 17:25.360] Okay yeah it's independent. [17:25.360 --> 17:26.360] Thank you. [17:26.360 --> 17:32.560] We don't have more time for questions but I think Felix is here and you can ask more [17:32.560 --> 17:37.320] questions afterwards. Thank you Felix.