WEBVTT

00:00.000 --> 00:19.080
All right, so hi there, I'm Adam and I've been using public transport since I started

00:19.080 --> 00:25.640
going to school and up till high school it was really easy and it any bus to the station

00:25.640 --> 00:33.480
and then it ran to school and back the same way and you knew it was something quite different

00:33.480 --> 00:40.200
and I couldn't find anything and I've enjoyed but I knew some Python and the time table was

00:40.200 --> 00:48.080
online so why not scrape it so this is what I did and fun fact I never got banned for this

00:48.080 --> 00:59.520
I got banned for subscribing to their RSS feed but fortunately in 2018 Post-Nan have

00:59.520 --> 01:07.640
come to their senses and start to really sing DFS files and later they created their own

01:07.640 --> 01:19.880
JSON API for real-time data with real-time data on stops and alerts and in 2019 they started

01:19.880 --> 01:29.360
publishing DFS RT with delays and vehicle positions but with no alerts and try to remember

01:29.360 --> 01:32.320
this for like three minutes yes

01:32.320 --> 01:38.140
two thousand four was enough to send them email that you won't schedule data as they

01:38.140 --> 01:50.920
complied okay I didn't notice and in 2004 I was like eight nine I was making post-Nan data

01:51.840 --> 02:05.920
okay all right so now since I used standard files so maybe I could just add another

02:05.920 --> 02:16.200
files and other places whenever I go for holiday yes in theory in 2024 someone knocked

02:16.200 --> 02:24.880
on my master on account asking if I know about transition I didn't know anything about

02:24.880 --> 02:34.320
transition I looked it up I had other plans but in October I had pretty much basic support

02:34.880 --> 02:50.280
implemented which gave me a only post-Nan but pretty much global coverage and yes so it's not only

02:50.280 --> 02:56.840
about writing code it's also about meeting people this is a photo from last year first

02:56.840 --> 03:07.600
open transport on conference I attended to and I met some great people and the idea

03:07.600 --> 03:18.080
came up there to maybe use that API just on API I talked about and query it and create

03:18.080 --> 03:25.680
DFS RT from this and put alerts and transitions and yes so it was my little contribution

03:25.680 --> 03:40.400
to transitions transition is not only gave me global coverage but also root planning this

03:40.400 --> 03:51.480
was always missing I never could have done it I never could have done myself but root planning

03:51.480 --> 04:00.160
is one thing and I thought about taking passenger by the hand and guiding him or guiding

04:00.160 --> 04:13.160
them all the way and I think this is great place to crowdsource data which segues really nice

04:13.240 --> 04:22.560
into the next talk I hope and for the future I hope to go full on transition and living my

04:22.560 --> 04:36.840
legacy back and behind this will make really very very much a lot of things easier and I hope

04:36.920 --> 04:46.920
that one day there will be an up for root planning for buying tickets for going on a trip

04:46.920 --> 04:57.400
and that even my grandmothers would be able to build that up so yay thank you

05:36.840 --> 06:06.800
for the recent years the trend in our general community was to move more parts of

06:06.800 --> 06:12.520
the infrastructure for public transport into open source components for example we now

06:12.520 --> 06:19.760
had a set of a routing we have we software apps that end users can use and we have deployments

06:19.760 --> 06:27.800
of these so it's kind of become practical to use so what could we do next and I think we should

06:27.880 --> 06:36.760
move this open slash proprietary water a bit further by also going into creating all of the

06:36.760 --> 06:43.640
necessary software to run a minimum public transport service at some point for example community

06:43.640 --> 06:49.800
buses can actually make use of this and that could include things like schedule creation digital

06:49.880 --> 06:57.640
signage and of course also return data processing so we can track vehicles and derive delays from

06:57.640 --> 07:04.200
there so this is also interesting beyond running community buses because some operators don't do

07:04.200 --> 07:13.960
this himself or don't publish it so it's helpful if we can just do it for them okay so my general

07:13.960 --> 07:18.680
plan was to just collect vehicle positions directly from the travelers because most of these

07:19.240 --> 07:24.760
phones and the phones have to be asked and we can just get the position of the vehicle from there

07:25.320 --> 07:30.680
then we can interpret these positions and derive the delay from that so

07:31.480 --> 07:37.080
what note regarding to be as reception in vehicles it's not always great but it's generally

07:37.080 --> 07:44.200
kind of good enough to get a basic idea where the vehicle is with all the modern improvements

07:44.200 --> 07:50.920
AGPS wireless network-based location and also getting it from onboard process of trains it should

07:50.920 --> 07:57.800
be mostly good enough so how should this look festival the user must have already opted in we

07:57.800 --> 08:02.840
can't just randomly send to PS positions of people's phones to some server without them known

08:03.720 --> 08:08.680
as soon as a user has searched for a trip in their trip plan I absolutely can remember that

08:08.680 --> 08:14.200
was searched for and as soon as the trip starts ask the user whether they want to share their

08:14.200 --> 08:22.600
location while the trip is ongoing and once that was agreed to we can just regularly send the GPS

08:22.600 --> 08:30.760
position to some API that API server should then just produce a regular GTI's RT vehicle

08:30.760 --> 08:36.760
position to field at this point it should no longer be any different from a operator supplied

08:36.840 --> 08:42.920
vehicle position feet so once we have these positions we need to derive the delay from them

08:43.640 --> 08:50.040
and there's already some prior art on that for example transit clock but while transit clock

08:50.040 --> 08:55.720
is known to have kind of good predictions it's also very hard to set up not actively maintained

08:55.720 --> 09:03.960
users lots of resources and is relatively unreliable so since my long term plan is to integrate

09:04.120 --> 09:11.640
this into a transition it will probably not work for Planet Terry scale so what I started was to

09:11.640 --> 09:18.040
do a very basic implementation of that that uses little resources and that has some chance to

09:18.040 --> 09:27.800
scale to that so the algorithm is currently extremely easy and basic as soon as we receive a new

09:27.800 --> 09:34.600
position of a vehicle we just remember that memory for now and once the vehicle is close to

09:34.600 --> 09:40.280
a stop that we know where the time when it should stop there we can tell whether the vehicle's on time

09:40.280 --> 09:46.280
or not if the vehicle is not on time because it has not arrived at the stop at the right time

09:46.280 --> 09:52.120
from a time-table we can calculate difference between time-table and the current time and know the delay

09:52.840 --> 09:57.240
and if there is no delay we can remember all the positions we had before

09:57.240 --> 10:04.680
and then we also can extend the timetable with time and position pairs in between the stops so that

10:04.680 --> 10:09.800
once the vehicle runs again we have some earlier predictions or earlier measurements at least

10:11.160 --> 10:16.760
in practice that looks like this we have some schedule we have the actual real-time results and

10:16.760 --> 10:24.120
the difference between them is then the result once we have these measurements from punctual trips

10:24.200 --> 10:31.240
we can add these just like the stops in between and then we can do the delay calculation as

10:31.240 --> 10:38.440
like bit earlier the result of that we can then expose in TTFS RT trip update feed

10:39.320 --> 10:45.320
and that can be consumed by regular routing software that all of you are probably already using

10:45.320 --> 10:53.480
like motors or open trip planer the idea is then that some application like boomer before

10:53.480 --> 10:59.960
can send a request like this with the at the first location of the device to an API that

10:59.960 --> 11:06.600
would look that looks like this in my implementation and the two mentioned components then

11:06.600 --> 11:14.280
derive the delay from it and we get a proper delay in motors displayed for some train for example that

11:14.360 --> 11:22.520
does not have official delay information and the next step is to just get this deployed in production

11:22.520 --> 11:28.200
and implement it in a few apps so we can actually use it and then we can of course improve the

11:28.200 --> 11:34.280
very basic algorithm but for now this should work