WEBVTT 00:00.000 --> 00:13.240 Yeah, I'm Robin, I'm actually working on motors, usually we've just heard about OTP, and 00:13.240 --> 00:20.440 motors is just another trip planner and time table information system, also open source, 00:20.440 --> 00:25.760 and motors is actually the software behind transitions that we have also heard about before 00:25.760 --> 00:26.760 today. 00:26.760 --> 00:30.640 Yeah, maybe we'll look at this a bit later, because today I'm talking about a private 00:30.640 --> 00:38.800 project of mine, which actually uses or leverages, motors and the transitions API to do 00:38.800 --> 00:45.320 the heavy lifting, to use global data without having to integrate all of that global data. 00:45.320 --> 00:52.120 And so yeah, I'm using it to do some probabilistic magic if you want, because I want to have 00:52.120 --> 00:57.080 probabilistic turn by turn directions for public transport. 00:57.080 --> 00:59.520 So what do I mean by that? 00:59.520 --> 01:06.640 If you go by car, then you use the GPS navigation system, then this navigation system will 01:06.640 --> 01:10.560 usually just tell you the next step that you will take, right? 01:10.560 --> 01:16.440 It will tell you, please turn right at the next exit, or please go straight on or whatever, 01:16.440 --> 01:24.560 and you as the driver don't have to worry about the tens of dozens of next steps down 01:24.560 --> 01:30.720 the road down the line, and the algorithm behind the system might actually change your route 01:30.720 --> 01:33.840 while you're traveling, while you're driving. 01:33.840 --> 01:38.320 But with public transport, that's not how things usually work. 01:38.320 --> 01:43.280 With public transport, you have one upfront journey plan, you say I want to go from 01:43.280 --> 01:49.400 it to B, and then you get one fixed journey plan, and people try to stick to this journey plan 01:49.400 --> 01:54.000 as long as they can, as long as they physically can, because then of course disruptions 01:54.000 --> 01:59.240 and delays come into play, but as long as they can, they will stick to this one single 01:59.240 --> 02:01.640 fixed journey plan. 02:01.640 --> 02:02.640 So why is that? 02:02.640 --> 02:08.640 Why don't we just do the same thing as when you're sitting in a car, just always telling 02:08.640 --> 02:11.800 you the best next step to take to get to your destination. 02:11.880 --> 02:16.840 I mean, usually I would say maybe we agree in this room, it's not a good idea to get inspired 02:16.840 --> 02:22.920 by cars, but in this case maybe, I don't know. 02:22.920 --> 02:31.400 So yeah, I first want to motivate this a bit more, why this classical point of view of this 02:31.400 --> 02:39.240 single fixed journey, and also this optimization for the shortest, the shortest travel time, 02:39.240 --> 02:47.280 and maybe the least amount of transfers, the usual Pareto optimization that trip plan 02:47.280 --> 02:56.280 is like motors and OTP do, is not always leading to ideal results for a user in reality. 02:56.280 --> 03:00.640 So for that, I'm using these time-space diagrams to illustrate that. 03:00.640 --> 03:08.680 So we have on the x-axis, we have space basically, so we have three stations in that case 03:08.680 --> 03:14.320 A, B, and D, and the user wants the curve from A to D, and we have the time dimension 03:14.320 --> 03:19.320 or time-axis, the y-axis, which progresses from top to bottom. 03:19.320 --> 03:24.280 And so a user who wants to arrive as early as possible at the destination D, wants to arrive 03:24.280 --> 03:29.000 as high up as possible here on the right. 03:29.000 --> 03:34.320 And so in this example, a classical journey planner would actually propose a connection 03:34.320 --> 03:40.800 3 for the user, because I'm assuming, in this example, that between connections 1 and 2, 03:40.800 --> 03:47.040 there is a transfer at the station B, and this is a very tight transfer of maybe 4 minutes, 03:47.040 --> 03:52.840 let's say, and with these classical trip planners, you usually have some fixed amount 03:52.840 --> 03:57.280 of transfer time that you're assuming for a certain station, or maybe for a certain length 03:57.280 --> 04:04.280 of footpath, and in that case, we would just exclude this obviously much shorter journey 04:05.040 --> 04:09.920 completely from the results, the user would never know about it. 04:09.920 --> 04:15.360 But they would just know about this connection 3, that brings them directly to the destination. 04:15.360 --> 04:18.680 But what if we had this adaptive view, right? 04:18.680 --> 04:25.760 We could try to take, or we could take connection 1, and actually try to make the transfer 04:25.760 --> 04:33.720 to connection 2, arrive much earlier D, and if that goes wrong, then we can still have some 04:33.760 --> 04:41.440 more transfer time and transfer to connection 4, and arrive barely later than we would 04:41.440 --> 04:47.200 have arrived according to the optimal journey plan that we would have been given by a classical 04:47.200 --> 04:48.680 trip planner, right? 04:48.680 --> 04:53.680 So we can't basically go wrong, because in the worst case, we won't be much later, 04:53.680 --> 04:59.560 and in the best case, we will be much earlier at the destination. 05:00.520 --> 05:03.760 Some other examples, backup transfers, right? 05:03.760 --> 05:11.760 Again, the reliability of transfers is the key thing to look at here, because a classical 05:11.760 --> 05:18.200 journey planner, in this case, we assume that here at this transfer at C, we have enough 05:18.200 --> 05:21.880 time according to a classical journey planner, but it's still quite tight, right? 05:21.880 --> 05:27.320 So I might miss it, and if I miss this connection from 1 to 2, I will actually need to take 05:27.320 --> 05:34.320 connection 6 down here, and I will arrive much later than I wanted to, instead maybe 05:34.320 --> 05:39.640 I should have opted for connection 3, because then even if I miss this tight connection 05:39.640 --> 05:45.520 here, this tight transfer to connection 4, then in this case, I have a better backup 05:45.520 --> 05:55.520 connection with connection 5, so even the worst case I arrived a bit earlier, and the 05:55.520 --> 06:01.360 opposite is also true for primary transfer, if the primary actually plan transfer is more 06:01.360 --> 06:08.720 reliable, then I'm actually maybe ready to arrive just a teeny tiny bit later at the destination, 06:08.720 --> 06:13.920 even if with the other connection, I would arrive a bit earlier, but the transfer is much 06:13.920 --> 06:16.920 more unlikely to actually work. 06:16.920 --> 06:20.840 Yes, and we can go this, we can drive this even further, right? 06:20.840 --> 06:31.080 In this example, if we arrive with connection 1 at stop B, if you optimize for reliable transfers, 06:31.080 --> 06:38.120 you would maybe propose connection 4 to the user, because in both cases you have a nice 06:38.120 --> 06:44.840 decent transfer time at stop B and C, but what stops you from telling the user, okay, you 06:44.840 --> 06:50.720 can try to take connection 2, if you succeed very good, then you have more transfer time 06:50.720 --> 06:56.240 at stop C, you might even, if you're lucky, and there's some delay in the system, which 06:56.240 --> 07:02.240 is great, the laser always great, because then the interesting stuff happens, you might 07:02.240 --> 07:06.680 even be able to do this negative transfer here, right, if a connection 3 is a bit delayed, 07:06.680 --> 07:11.000 then you might actually make the transfer to connection 3, and if not, it's not bad, 07:11.000 --> 07:16.840 you just take connection 5 as you were intended to do initially, and yeah, definitely 07:16.840 --> 07:22.680 it's better than connection 4, because you have better transfer a reliability of transfer, 07:22.680 --> 07:24.680 that's the idea. 07:24.680 --> 07:29.520 So yeah, what's the solution to all of these problems or questions, it's of course probabilities, 07:29.520 --> 07:35.520 because of this reliability questions and so on, it's just the probability that I make 07:35.520 --> 07:41.040 a transfer, the probability by how much the train will be delayed and so on and so forth. 07:41.040 --> 07:47.920 So what I do in this system or algorithm is I have a destination, a driver distribution 07:47.920 --> 07:54.640 of the connections arriving at the destination, the user has picked, so that would be the 07:54.640 --> 08:00.520 blue and the black histogram that is turned by 90 degrees, if you can imagine, right, 08:00.520 --> 08:05.480 so there's usually the train will be on time, but there is a certain probability that 08:05.560 --> 08:11.960 it will be a bit delayed, and then if I want to calculate the destination arrival distribution 08:11.960 --> 08:21.520 of the connection 1, it's some kind of weighted average of these two destination arrival 08:21.520 --> 08:27.960 distributions of connection 2 and 3 in that case, right, yes. 08:27.960 --> 08:34.160 So yeah, that's the approach, we don't want to have this upfront fixed journey plan, it's 08:34.160 --> 08:41.160 just a silver work on a planet scale, time table ideally, and yeah, we want to calculate 08:41.160 --> 08:46.960 these probability distributions of destination arrival based on the arrival and departure 08:46.960 --> 08:54.760 distributions that we get from historical real-time delay, data, and yeah, one more thing 08:54.760 --> 09:00.560 that I'm using, so that I can actually easily leverage the transition start without having 09:00.640 --> 09:06.480 to load all of the global time table data into my system, is the heuristic of relevant 09:06.480 --> 09:14.120 stops that I just look at the possible transfers that classical journey plan I would actually 09:14.120 --> 09:21.120 also find, but yeah, that's a heuristic simplification that I'm using, so that we can, this 09:21.200 --> 09:29.200 is a French keyboard, but they're with me, so the advantage of the life demos, yes, is that 09:30.200 --> 09:38.200 it's more stressful for me, and more fun for you, hopefully, there we go. So, and it's 09:39.200 --> 09:45.200 an advantage of the life demos, yes, is that it's more stressful for me, and more fun 09:49.200 --> 09:58.200 for you, hopefully, there we go. So, and it's in French as well, so let's switch to English 09:58.200 --> 10:05.200 for the majority of the audience, and then we can just, as in a normal journey plan, we can, 10:08.200 --> 10:14.200 yes, we can plan a journey from a source to a destination, for instance, let's go to 10:14.200 --> 10:24.200 the hege, maybe, let's maybe go to the heikh's central, and then we notice that we have to 10:24.200 --> 10:37.200 improve on the, yeah, on the geopoder of modes, so this is the, I just did a request to modes, 10:37.200 --> 10:44.200 or the transition API, and the background, which is just a classical plan request, and now 10:44.200 --> 10:50.200 I'm catching for all of the possibly relevant stations, I'm catching the time table data, 10:50.200 --> 10:59.200 building is more timetable out of that, and then I can, how do you do that, very good. 11:00.200 --> 11:07.200 I can, yeah, calculate all the distributions, the probability distributions were some 11:07.200 --> 11:14.200 that, so the important idea, again, is we don't see the complete, we don't see 11:14.200 --> 11:20.200 the complete journey here, right, we just see the departures from brushless media train station right now, 11:20.200 --> 11:26.200 so we see, okay, if I go, when I go to the heikh's central, I can just, I can either take 11:26.200 --> 11:32.200 the euro star, or I can take a euro city, or I can take another euro star, half an hour later, 11:32.200 --> 11:38.200 right, and here on the right side, we see the destination arrival at the heikh, right, 11:38.200 --> 11:46.200 and it's actually showing me the histograms of destination arrival at that station, so in this case, 11:46.200 --> 11:54.200 my most, my average arrival at the heikh's central will be at 1940, if I take the next train, 11:54.200 --> 12:03.200 my average arrival will be at 1945, 54, and so on and so forth, right, and then I can decide, 12:03.200 --> 12:08.200 okay, now you can imagine, you would be hopping on that train, let's take the euro star, maybe, 12:08.200 --> 12:14.200 so you decide to take the train, okay, now I'm on this train, and the next relevant 12:14.200 --> 12:19.200 stop would be Rotterdam central, and so no, being at Rotterdam central, and he did the 12:19.200 --> 12:24.200 side, which train to take next, right, because before I don't know the interior, I don't 12:24.200 --> 12:31.200 need to worry about this, and here I see, okay, I arrive at 1902 at Rotterdam central, 12:31.200 --> 12:37.200 and finally enough there is at 1902, there is a train leaving to then half central, which 12:37.200 --> 12:45.200 would make me arrive actually at 1934 already, which would be great, but I have zero 12:45.200 --> 12:51.200 minutes of transfer time, okay, I can try, again, I can try to get it, maybe it has a 12:51.200 --> 12:55.200 one or two minutes delay, and I easily get it, maybe my arriving train has a bit of 12:55.200 --> 13:01.200 is arriving with early, if not, no problem, then I'm just looking, okay, then my next option 13:01.200 --> 13:11.200 would be the 1906, was printer that I can take to then ask Hs, though, the heikh Hs, 13:11.200 --> 13:17.200 or which, the thing which transitions, or based on transitions we're proposing is actually 13:17.200 --> 13:24.200 the flicks pass, okay, that could be interesting, but let's maybe up for another 13:24.200 --> 13:32.200 backup, at 1920 I can also take another train to the heikh central direct, and then I only 13:32.200 --> 13:40.200 arrive at 1952, on average, it says, right, but then I have already arrived with only two 13:41.200 --> 13:47.200 transfers, if I had at Rotterdam chosen another train, for instance, the 13:47.200 --> 13:52.200 printer, right, I see here the distribution is much broader, because there is another 13:52.200 --> 14:00.200 transfer, I don't arrive directly at the heikh, but I arrive at the heikh, high 14:00.200 --> 14:09.200 speed probably that means, okay, then not high speed, but something, Hs, and I can, 14:09.200 --> 14:14.200 yeah, I can see how to continue further, probably some bus that I'm taking then, 14:14.200 --> 14:21.200 if I really wanted to go to, then Hs central, all right, then how much time do I have, 14:21.200 --> 14:28.200 sorry, okay, great, then I'm just skipping this maybe, or yeah, we have seen the 14:28.200 --> 14:33.200 destination arrival distributions, and what I think is maybe important to see in this 14:33.200 --> 14:38.200 example, again, the mean of the distribution is not, so the average of the distribution is 14:38.200 --> 14:43.200 not necessarily something very intuitive, right, because you might have a big peak here, 14:43.200 --> 14:47.200 where it's very likely to arrive, and you have a big peak here, where it's very likely to arrive, 14:47.200 --> 14:53.200 so the mean is somewhere in the middle, and it's not necessarily very intuitive. 14:53.200 --> 14:58.200 Yeah, long story short, you can actually simulation show that you can actually arrive 14:58.200 --> 15:03.200 earlier, on average, you can actually make up for delays, even if you follow that 15:03.200 --> 15:10.200 idea, exactly, maybe you need to be a bit more nimble, and if you have lots of 15:10.200 --> 15:16.200 luggage, and so on, maybe you have other priorities, and of course, it also depends on 15:16.200 --> 15:22.200 ticketing, but I think actually in many cases, you have that flexibility, if you have 15:22.200 --> 15:28.200 relation tickets, or regional tickets, or general general abnormal or bank hat 15:28.200 --> 15:34.200 hundra, or Dutch and ticket, interior tickets, whatever, then this can be interesting. 15:34.200 --> 15:39.200 If you really wanted to limit yourself to a specific terrain, then interestingly, all 15:39.200 --> 15:44.200 the calculation would somehow break down, and you would rather want to have more reliable 15:44.200 --> 15:51.200 transfers in general, right, but on one single connection. Yeah, and maybe you, one day 15:51.200 --> 15:56.200 we will, I will be able to integrate this into modus, and thereby transition. 15:56.200 --> 16:01.200 What I would be interested in, if we have some time, is if you come up with additional criteria 16:01.200 --> 16:07.200 that would be interesting for considering the quality of an itinerary or journey plan, whether 16:07.200 --> 16:11.200 it be probabilistic or not, or if you have any other questions, we've got in transition 16:11.200 --> 16:12.200 or whatever. 16:12.200 --> 16:19.200 So, for one and two from your demo, you need to provide a solution, or a route 16:19.200 --> 16:25.200 solution, or you need to provide it connections roughly on the side. 16:25.200 --> 16:30.200 Yeah. Might to go use cases, a computing, the trial from Paris to 16:30.200 --> 16:36.200 Villain, so that's a low weight, 29 hours, or 30, plus and about 9 connections, 16:36.200 --> 16:37.200 given the. 16:37.200 --> 16:42.200 Yeah, you can, so, the question, repeating the question, whether we need to know the 16:42.200 --> 16:48.200 connections or a itinerary upfront, well, no, you can enter it there. 16:48.200 --> 16:52.200 It will get the information from transition. 16:52.200 --> 16:57.200 It will maybe take a bit longer with the journey from Villainus to what is, 16:57.200 --> 17:02.200 to Paris Villainus, okay, that's quite far, but with nine transfers, I mean, 17:02.200 --> 17:06.200 that's the perfect playing field for T-space, because the more transfers, 17:06.200 --> 17:11.200 the better, right? 17:11.200 --> 17:15.200 So, yeah, but it would be an improvement if you would actually calculate it on the entire 17:15.200 --> 17:22.200 time table, because sometimes you're missing interesting transfer possibilities like that. 17:22.200 --> 17:26.200 Yeah, I don't remember who, I think you were longer, and then. 17:26.200 --> 17:33.200 How do you predict the distribution of a rival time, where the difference is a train versus 17:33.200 --> 17:34.200 buster? 17:34.200 --> 17:39.200 Yes, so there is also like all sorts of public transport, local public transport in there. 17:40.200 --> 17:46.200 Yeah, based on historical real-time data, GTFSRT collected, and then you just, 17:46.200 --> 17:52.200 I mean, especially based on the current predicted delay, that is also a key factor. 17:52.200 --> 17:56.200 I think if the train is already delayed by 30 minutes, you have a completely different distribution. 17:56.200 --> 18:01.200 But yeah, by historic data that I've collected, in this case, it's actually a bit cheated, 18:01.200 --> 18:07.200 because it's based on German data, but I mean, roughly, yeah. 18:07.200 --> 18:08.200 Who else? 18:08.200 --> 18:09.200 I mean, you're interested. 18:09.200 --> 18:11.200 You're interested, my question. 18:11.200 --> 18:12.200 Okay. 18:12.200 --> 18:14.200 And I forgot to repeat the question, but I think it was clear. 18:14.200 --> 18:15.200 Yes. 18:15.200 --> 18:20.200 What do you think anything about, like, what's more, you may not just do more of the 18:20.200 --> 18:25.200 loss of survival time, but for just cases such as a hard deadline, you need to be there, 18:25.200 --> 18:28.200 poor or low value, just starting before some days and hours. 18:28.200 --> 18:29.200 Yeah. 18:29.200 --> 18:30.200 Yes. 18:30.200 --> 18:34.200 So, whether we have considered optimizing for deadline arrival, there's actually 18:34.200 --> 18:38.200 a certain direction, and it would also be an interesting option. 18:38.200 --> 18:39.200 Yes. 18:39.200 --> 18:45.200 I mean, I do include the 95% arrival in here, the third time that you see here, is the 95% arrival. 18:45.200 --> 18:50.200 So, until that time you have arrived, but with the probability of 95% in theory. 18:50.200 --> 18:55.200 But you could also inverse all of that, and it would also be an interesting application for sure. 18:55.200 --> 18:56.200 Yes. 18:56.200 --> 18:57.200 Yes. 18:57.200 --> 18:58.200 Okay. 18:58.200 --> 19:00.200 Can I already use this today? 19:00.200 --> 19:01.200 Yes. 19:01.200 --> 19:02.200 There's no train at all. 19:02.200 --> 19:07.200 They open, like, I keep this open on my phone, and it keeps updating with the real time they have. 19:07.200 --> 19:13.200 Well, currently to limit data consumption, you need to press on this refresh button. 19:13.200 --> 19:14.200 Okay. 19:14.200 --> 19:16.200 But it remembers where you are, and so on. 19:16.200 --> 19:17.200 Amazing. 19:17.200 --> 19:18.200 Yep. 19:18.200 --> 19:21.200 Go ahead, use it. 19:21.200 --> 19:22.200 That's what it's for. 19:22.200 --> 19:25.200 It's actually trying to make it easier for me. 19:25.200 --> 19:28.200 You asked about extra criteria that will make it better. 19:28.200 --> 19:29.200 Yes. 19:29.200 --> 19:32.200 I need to talk about the nine stop connection. 19:32.200 --> 19:36.200 I would think it would be really cool to know if there's the kind of station that I'm stopping at there. 19:36.200 --> 19:37.200 I don't know. 19:37.200 --> 19:38.200 I don't know. 19:38.200 --> 19:40.200 And so, it's as like Western one or anything. 19:40.200 --> 19:45.200 I would prefer that station to be stuck there, rather than a small station for girls. 19:45.200 --> 19:46.200 Yes. 19:46.200 --> 19:49.200 That would be really neat to know about that. 19:49.200 --> 19:50.200 Yeah. 19:50.200 --> 19:55.200 In some sense, that's, I mean, it's a really interesting criterion for that we definitely should remember. 19:55.200 --> 20:00.200 I think for tea space, it's against the philosophy that you don't know where you will end up. 20:00.200 --> 20:01.200 Basically, right? 20:01.200 --> 20:04.200 But it's definitely an important thing. 20:04.200 --> 20:09.200 That's also maybe a bit difficult to encode in an algorithm. 20:09.200 --> 20:11.200 Thanks. 20:11.200 --> 20:14.200 Who was first about the time of the episode? 20:14.200 --> 20:15.200 Sorry. 20:15.200 --> 20:16.200 But you can get in touch with me. 20:16.200 --> 20:18.200 I will be around if you want. 20:25.200 --> 20:27.200 Thank you.