Yeah, I'm Robin, I'm actually working on motors, usually we've just heard about OTP, and
motors is just another trip planner and time table information system, also open source,
and motors is actually the software behind transitions that we have also heard about before
today.
Yeah, maybe we'll look at this a bit later, because today I'm talking about a private
project of mine, which actually uses or leverages, motors and the transitions API to do
the heavy lifting, to use global data without having to integrate all of that global data.
And so yeah, I'm using it to do some probabilistic magic if you want, because I want to have
probabilistic turn by turn directions for public transport.
So what do I mean by that?
If you go by car, then you use the GPS navigation system, then this navigation system will
usually just tell you the next step that you will take, right?
It will tell you, please turn right at the next exit, or please go straight on or whatever,
and you as the driver don't have to worry about the tens of dozens of next steps down
the road down the line, and the algorithm behind the system might actually change your route
while you're traveling, while you're driving.
But with public transport, that's not how things usually work.
With public transport, you have one upfront journey plan, you say I want to go from
it to B, and then you get one fixed journey plan, and people try to stick to this journey plan
as long as they can, as long as they physically can, because then of course disruptions
and delays come into play, but as long as they can, they will stick to this one single
fixed journey plan.
So why is that?
Why don't we just do the same thing as when you're sitting in a car, just always telling
you the best next step to take to get to your destination.
I mean, usually I would say maybe we agree in this room, it's not a good idea to get inspired
by cars, but in this case maybe, I don't know.
So yeah, I first want to motivate this a bit more, why this classical point of view of this
single fixed journey, and also this optimization for the shortest, the shortest travel time,
and maybe the least amount of transfers, the usual Pareto optimization that trip plan
is like motors and OTP do, is not always leading to ideal results for a user in reality.
So for that, I'm using these time-space diagrams to illustrate that.
So we have on the x-axis, we have space basically, so we have three stations in that case
A, B, and D, and the user wants the curve from A to D, and we have the time dimension
or time-axis, the y-axis, which progresses from top to bottom.
And so a user who wants to arrive as early as possible at the destination D, wants to arrive
as high up as possible here on the right.
And so in this example, a classical journey planner would actually propose a connection
3 for the user, because I'm assuming, in this example, that between connections 1 and 2,
there is a transfer at the station B, and this is a very tight transfer of maybe 4 minutes,
let's say, and with these classical trip planners, you usually have some fixed amount
of transfer time that you're assuming for a certain station, or maybe for a certain length
of footpath, and in that case, we would just exclude this obviously much shorter journey
completely from the results, the user would never know about it.
But they would just know about this connection 3, that brings them directly to the destination.
But what if we had this adaptive view, right?
We could try to take, or we could take connection 1, and actually try to make the transfer
to connection 2, arrive much earlier D, and if that goes wrong, then we can still have some
more transfer time and transfer to connection 4, and arrive barely later than we would
have arrived according to the optimal journey plan that we would have been given by a classical
trip planner, right?
So we can't basically go wrong, because in the worst case, we won't be much later,
and in the best case, we will be much earlier at the destination.
Some other examples, backup transfers, right?
Again, the reliability of transfers is the key thing to look at here, because a classical
journey planner, in this case, we assume that here at this transfer at C, we have enough
time according to a classical journey planner, but it's still quite tight, right?
So I might miss it, and if I miss this connection from 1 to 2, I will actually need to take
connection 6 down here, and I will arrive much later than I wanted to, instead maybe
I should have opted for connection 3, because then even if I miss this tight connection
here, this tight transfer to connection 4, then in this case, I have a better backup
connection with connection 5, so even the worst case I arrived a bit earlier, and the
opposite is also true for primary transfer, if the primary actually plan transfer is more
reliable, then I'm actually maybe ready to arrive just a teeny tiny bit later at the destination,
even if with the other connection, I would arrive a bit earlier, but the transfer is much
more unlikely to actually work.
Yes, and we can go this, we can drive this even further, right?
In this example, if we arrive with connection 1 at stop B, if you optimize for reliable transfers,
you would maybe propose connection 4 to the user, because in both cases you have a nice
decent transfer time at stop B and C, but what stops you from telling the user, okay, you
can try to take connection 2, if you succeed very good, then you have more transfer time
at stop C, you might even, if you're lucky, and there's some delay in the system, which
is great, the laser always great, because then the interesting stuff happens, you might
even be able to do this negative transfer here, right, if a connection 3 is a bit delayed,
then you might actually make the transfer to connection 3, and if not, it's not bad,
you just take connection 5 as you were intended to do initially, and yeah, definitely
it's better than connection 4, because you have better transfer a reliability of transfer,
that's the idea.
So yeah, what's the solution to all of these problems or questions, it's of course probabilities,
because of this reliability questions and so on, it's just the probability that I make
a transfer, the probability by how much the train will be delayed and so on and so forth.
So what I do in this system or algorithm is I have a destination, a driver distribution
of the connections arriving at the destination, the user has picked, so that would be the
blue and the black histogram that is turned by 90 degrees, if you can imagine, right,
so there's usually the train will be on time, but there is a certain probability that
it will be a bit delayed, and then if I want to calculate the destination arrival distribution
of the connection 1, it's some kind of weighted average of these two destination arrival
distributions of connection 2 and 3 in that case, right, yes.
So yeah, that's the approach, we don't want to have this upfront fixed journey plan, it's
just a silver work on a planet scale, time table ideally, and yeah, we want to calculate
these probability distributions of destination arrival based on the arrival and departure
distributions that we get from historical real-time delay, data, and yeah, one more thing
that I'm using, so that I can actually easily leverage the transition start without having
to load all of the global time table data into my system, is the heuristic of relevant
stops that I just look at the possible transfers that classical journey plan I would actually
also find, but yeah, that's a heuristic simplification that I'm using, so that we can, this
is a French keyboard, but they're with me, so the advantage of the life demos, yes, is that
it's more stressful for me, and more fun for you, hopefully, there we go. So, and it's
an advantage of the life demos, yes, is that it's more stressful for me, and more fun
for you, hopefully, there we go. So, and it's in French as well, so let's switch to English
for the majority of the audience, and then we can just, as in a normal journey plan, we can,
yes, we can plan a journey from a source to a destination, for instance, let's go to
the hege, maybe, let's maybe go to the heikh's central, and then we notice that we have to
improve on the, yeah, on the geopoder of modes, so this is the, I just did a request to modes,
or the transition API, and the background, which is just a classical plan request, and now
I'm catching for all of the possibly relevant stations, I'm catching the time table data,
building is more timetable out of that, and then I can, how do you do that, very good.
I can, yeah, calculate all the distributions, the probability distributions were some
that, so the important idea, again, is we don't see the complete, we don't see
the complete journey here, right, we just see the departures from brushless media train station right now,
so we see, okay, if I go, when I go to the heikh's central, I can just, I can either take
the euro star, or I can take a euro city, or I can take another euro star, half an hour later,
right, and here on the right side, we see the destination arrival at the heikh, right,
and it's actually showing me the histograms of destination arrival at that station, so in this case,
my most, my average arrival at the heikh's central will be at 1940, if I take the next train,
my average arrival will be at 1945, 54, and so on and so forth, right, and then I can decide,
okay, now you can imagine, you would be hopping on that train, let's take the euro star, maybe,
so you decide to take the train, okay, now I'm on this train, and the next relevant
stop would be Rotterdam central, and so no, being at Rotterdam central, and he did the
side, which train to take next, right, because before I don't know the interior, I don't
need to worry about this, and here I see, okay, I arrive at 1902 at Rotterdam central,
and finally enough there is at 1902, there is a train leaving to then half central, which
would make me arrive actually at 1934 already, which would be great, but I have zero
minutes of transfer time, okay, I can try, again, I can try to get it, maybe it has a
one or two minutes delay, and I easily get it, maybe my arriving train has a bit of
is arriving with early, if not, no problem, then I'm just looking, okay, then my next option
would be the 1906, was printer that I can take to then ask Hs, though, the heikh Hs,
or which, the thing which transitions, or based on transitions we're proposing is actually
the flicks pass, okay, that could be interesting, but let's maybe up for another
backup, at 1920 I can also take another train to the heikh central direct, and then I only
arrive at 1952, on average, it says, right, but then I have already arrived with only two
transfers, if I had at Rotterdam chosen another train, for instance, the
printer, right, I see here the distribution is much broader, because there is another
transfer, I don't arrive directly at the heikh, but I arrive at the heikh, high
speed probably that means, okay, then not high speed, but something, Hs, and I can,
yeah, I can see how to continue further, probably some bus that I'm taking then,
if I really wanted to go to, then Hs central, all right, then how much time do I have,
sorry, okay, great, then I'm just skipping this maybe, or yeah, we have seen the
destination arrival distributions, and what I think is maybe important to see in this
example, again, the mean of the distribution is not, so the average of the distribution is
not necessarily something very intuitive, right, because you might have a big peak here,
where it's very likely to arrive, and you have a big peak here, where it's very likely to arrive,
so the mean is somewhere in the middle, and it's not necessarily very intuitive.
Yeah, long story short, you can actually simulation show that you can actually arrive
earlier, on average, you can actually make up for delays, even if you follow that
idea, exactly, maybe you need to be a bit more nimble, and if you have lots of
luggage, and so on, maybe you have other priorities, and of course, it also depends on
ticketing, but I think actually in many cases, you have that flexibility, if you have
relation tickets, or regional tickets, or general general abnormal or bank hat
hundra, or Dutch and ticket, interior tickets, whatever, then this can be interesting.
If you really wanted to limit yourself to a specific terrain, then interestingly, all
the calculation would somehow break down, and you would rather want to have more reliable
transfers in general, right, but on one single connection. Yeah, and maybe you, one day
we will, I will be able to integrate this into modus, and thereby transition.
What I would be interested in, if we have some time, is if you come up with additional criteria
that would be interesting for considering the quality of an itinerary or journey plan, whether
it be probabilistic or not, or if you have any other questions, we've got in transition
or whatever.
So, for one and two from your demo, you need to provide a solution, or a route
solution, or you need to provide it connections roughly on the side.
Yeah. Might to go use cases, a computing, the trial from Paris to
Villain, so that's a low weight, 29 hours, or 30, plus and about 9 connections,
given the.
Yeah, you can, so, the question, repeating the question, whether we need to know the
connections or a itinerary upfront, well, no, you can enter it there.
It will get the information from transition.
It will maybe take a bit longer with the journey from Villainus to what is,
to Paris Villainus, okay, that's quite far, but with nine transfers, I mean,
that's the perfect playing field for T-space, because the more transfers,
the better, right?
So, yeah, but it would be an improvement if you would actually calculate it on the entire
time table, because sometimes you're missing interesting transfer possibilities like that.
Yeah, I don't remember who, I think you were longer, and then.
How do you predict the distribution of a rival time, where the difference is a train versus
buster?
Yes, so there is also like all sorts of public transport, local public transport in there.
Yeah, based on historical real-time data, GTFSRT collected, and then you just,
I mean, especially based on the current predicted delay, that is also a key factor.
I think if the train is already delayed by 30 minutes, you have a completely different distribution.
But yeah, by historic data that I've collected, in this case, it's actually a bit cheated,
because it's based on German data, but I mean, roughly, yeah.
Who else?
I mean, you're interested.
You're interested, my question.
Okay.
And I forgot to repeat the question, but I think it was clear.
Yes.
What do you think anything about, like, what's more, you may not just do more of the
loss of survival time, but for just cases such as a hard deadline, you need to be there,
poor or low value, just starting before some days and hours.
Yeah.
Yes.
So, whether we have considered optimizing for deadline arrival, there's actually
a certain direction, and it would also be an interesting option.
Yes.
I mean, I do include the 95% arrival in here, the third time that you see here, is the 95% arrival.
So, until that time you have arrived, but with the probability of 95% in theory.
But you could also inverse all of that, and it would also be an interesting application for sure.
Yes.
Okay.
Can I already use this today?
Yes.
There's no train at all.
They open, like, I keep this open on my phone, and it keeps updating with the real time they have.
Well, currently to limit data consumption, you need to press on this refresh button.
Okay.
But it remembers where you are, and so on.
Amazing.
Yep.
Go ahead, use it.
That's what it's for.
It's actually trying to make it easier for me.
You asked about extra criteria that will make it better.
Yes.
I need to talk about the nine stop connection.
I would think it would be really cool to know if there's the kind of station that I'm stopping at there.
I don't know.
And so, it's as like Western one or anything.
I would prefer that station to be stuck there, rather than a small station for girls.
Yes.
That would be really neat to know about that.
Yeah.
In some sense, that's, I mean, it's a really interesting criterion for that we definitely should remember.
I think for tea space, it's against the philosophy that you don't know where you will end up.
Basically, right?
But it's definitely an important thing.
That's also maybe a bit difficult to encode in an algorithm.
Thanks.
Who was first about the time of the episode?
Sorry.
But you can get in touch with me.
I will be around if you want.
Thank you.