All right, so hi there, I'm Adam and I've been using public transport since I started
going to school and up till high school it was really easy and it any bus to the station
and then it ran to school and back the same way and you knew it was something quite different
and I couldn't find anything and I've enjoyed but I knew some Python and the time table was
online so why not scrape it so this is what I did and fun fact I never got banned for this
I got banned for subscribing to their RSS feed but fortunately in 2018 Post-Nan have
come to their senses and start to really sing DFS files and later they created their own
JSON API for real-time data with real-time data on stops and alerts and in 2019 they started
publishing DFS RT with delays and vehicle positions but with no alerts and try to remember
this for like three minutes yes
two thousand four was enough to send them email that you won't schedule data as they
complied okay I didn't notice and in 2004 I was like eight nine I was making post-Nan data
okay all right so now since I used standard files so maybe I could just add another
files and other places whenever I go for holiday yes in theory in 2024 someone knocked
on my master on account asking if I know about transition I didn't know anything about
transition I looked it up I had other plans but in October I had pretty much basic support
implemented which gave me a only post-Nan but pretty much global coverage and yes so it's not only
about writing code it's also about meeting people this is a photo from last year first
open transport on conference I attended to and I met some great people and the idea
came up there to maybe use that API just on API I talked about and query it and create
DFS RT from this and put alerts and transitions and yes so it was my little contribution
to transitions transition is not only gave me global coverage but also root planning this
was always missing I never could have done it I never could have done myself but root planning
is one thing and I thought about taking passenger by the hand and guiding him or guiding
them all the way and I think this is great place to crowdsource data which segues really nice
into the next talk I hope and for the future I hope to go full on transition and living my
legacy back and behind this will make really very very much a lot of things easier and I hope
that one day there will be an up for root planning for buying tickets for going on a trip
and that even my grandmothers would be able to build that up so yay thank you
for the recent years the trend in our general community was to move more parts of
the infrastructure for public transport into open source components for example we now
had a set of a routing we have we software apps that end users can use and we have deployments
of these so it's kind of become practical to use so what could we do next and I think we should
move this open slash proprietary water a bit further by also going into creating all of the
necessary software to run a minimum public transport service at some point for example community
buses can actually make use of this and that could include things like schedule creation digital
signage and of course also return data processing so we can track vehicles and derive delays from
there so this is also interesting beyond running community buses because some operators don't do
this himself or don't publish it so it's helpful if we can just do it for them okay so my general
plan was to just collect vehicle positions directly from the travelers because most of these
phones and the phones have to be asked and we can just get the position of the vehicle from there
then we can interpret these positions and derive the delay from that so
what note regarding to be as reception in vehicles it's not always great but it's generally
kind of good enough to get a basic idea where the vehicle is with all the modern improvements
AGPS wireless network-based location and also getting it from onboard process of trains it should
be mostly good enough so how should this look festival the user must have already opted in we
can't just randomly send to PS positions of people's phones to some server without them known
as soon as a user has searched for a trip in their trip plan I absolutely can remember that
was searched for and as soon as the trip starts ask the user whether they want to share their
location while the trip is ongoing and once that was agreed to we can just regularly send the GPS
position to some API that API server should then just produce a regular GTI's RT vehicle
position to field at this point it should no longer be any different from a operator supplied
vehicle position feet so once we have these positions we need to derive the delay from them
and there's already some prior art on that for example transit clock but while transit clock
is known to have kind of good predictions it's also very hard to set up not actively maintained
users lots of resources and is relatively unreliable so since my long term plan is to integrate
this into a transition it will probably not work for Planet Terry scale so what I started was to
do a very basic implementation of that that uses little resources and that has some chance to
scale to that so the algorithm is currently extremely easy and basic as soon as we receive a new
position of a vehicle we just remember that memory for now and once the vehicle is close to
a stop that we know where the time when it should stop there we can tell whether the vehicle's on time
or not if the vehicle is not on time because it has not arrived at the stop at the right time
from a time-table we can calculate difference between time-table and the current time and know the delay
and if there is no delay we can remember all the positions we had before
and then we also can extend the timetable with time and position pairs in between the stops so that
once the vehicle runs again we have some earlier predictions or earlier measurements at least
in practice that looks like this we have some schedule we have the actual real-time results and
the difference between them is then the result once we have these measurements from punctual trips
we can add these just like the stops in between and then we can do the delay calculation as
like bit earlier the result of that we can then expose in TTFS RT trip update feed
and that can be consumed by regular routing software that all of you are probably already using
like motors or open trip planer the idea is then that some application like boomer before
can send a request like this with the at the first location of the device to an API that
would look that looks like this in my implementation and the two mentioned components then
derive the delay from it and we get a proper delay in motors displayed for some train for example that
does not have official delay information and the next step is to just get this deployed in production
and implement it in a few apps so we can actually use it and then we can of course improve the
very basic algorithm but for now this should work