Okay, over 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 are there's a free software routing, we have free 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 source 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 them.
So this is also interesting beyond running community buses because some operators don't
do this themselves 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 carry 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 try not regarding to be asked 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 at GPS while it's network based location and also getting it from onboard
process of trains, it should be mostly good enough.
So how should this look, first of all, the user must have already opted in.
We can't just randomly send to GPS positions of people's phones to some server with
the phone.
As soon as a user has searched for a trip in their trip plan, I have the app can remember
that it 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.
The API server should then just produce a regular GPS RT vehicle position 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, while transit clock is known to have kind of good predictions,
there's also very hard to set up, not actively maintained, uses lots of resources and is
relatively unreliable.
So since my long term plan is to integrate this into the transition, it will probably not
work for Planet Terry's 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 in 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
vehicles on time are not.
If the vehicle is not on time because it has not arrived at the stop at the right time
from the 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 time table 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 a bit earlier.
The result of that, we can then expose in GTFSRT 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
planner.
The idea is then that some application like BIMBA before can send a request like this with the
GPS location of the device to an API 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.
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.