WEBVTT 00:00.000 --> 00:19.280 Okay, over the recent years, the trend in our general community was to move more parts 00:19.280 --> 00:24.520 of the infrastructure for public transport into open source components. 00:24.520 --> 00:30.160 For example, we now are there's a free software routing, we have free software apps that 00:30.160 --> 00:36.440 end users can use and we have deployments of these so it's kind of become practical to use. 00:36.440 --> 00:39.200 So what could we do next? 00:39.200 --> 00:46.800 And I think we should move this open source proprietary water a bit further by also going 00:46.800 --> 00:54.160 into creating all of the necessary software to run a minimum public transport service at 00:54.160 --> 00:55.160 some point. 00:55.160 --> 01:00.800 For example, community buses can actually make use of this and that could include things 01:00.800 --> 01:07.120 like schedule creation, digital signage and of course also return data processing so we 01:07.120 --> 01:11.680 can track vehicles and derive delays from them. 01:11.680 --> 01:16.720 So this is also interesting beyond running community buses because some operators don't 01:16.720 --> 01:24.120 do this themselves or don't publish it so it's helpful if we can just do it for them. 01:24.120 --> 01:29.840 Okay, so my general plan was to just collect vehicle positions directly from the 01:29.840 --> 01:34.600 travelers because most of these carry phones and the phones have to be asked and we can 01:34.600 --> 01:38.280 just get the position of the vehicle from there. 01:38.280 --> 01:42.480 Then we can interpret these positions and derive the delay from that. 01:42.480 --> 01:49.120 So try not regarding to be asked reception in vehicles, it's not always great but it's 01:49.120 --> 01:56.360 generally kind of good enough to get a basic idea where the vehicle is with all the modern 01:56.360 --> 02:02.040 improvements at GPS while it's network based location and also getting it from onboard 02:02.040 --> 02:06.240 process of trains, it should be mostly good enough. 02:06.240 --> 02:10.400 So how should this look, first of all, the user must have already opted in. 02:10.400 --> 02:14.920 We can't just randomly send to GPS positions of people's phones to some server with 02:14.920 --> 02:15.920 the phone. 02:15.920 --> 02:21.200 As soon as a user has searched for a trip in their trip plan, I have the app can remember 02:21.200 --> 02:25.440 that it was searched for and as soon as the trip starts, ask the user whether they want 02:25.440 --> 02:33.840 to share their location while the trip is ongoing and once that was agreed to, we can 02:33.840 --> 02:39.320 just regularly send the GPS position to some API. 02:39.320 --> 02:45.200 The API server should then just produce a regular GPS RT vehicle position field at this 02:45.200 --> 02:46.200 point. 02:46.200 --> 02:51.760 It should no longer be any different from a operator supplied vehicle position feet. 02:51.760 --> 02:58.040 So once we have these positions, we need to derive the delay from them and there's already 02:58.040 --> 02:59.360 some prior art on that. 02:59.360 --> 03:05.560 For example, transit clock, while transit clock is known to have kind of good predictions, 03:05.560 --> 03:10.800 there's also very hard to set up, not actively maintained, uses lots of resources and is 03:10.800 --> 03:12.920 relatively unreliable. 03:12.920 --> 03:19.640 So since my long term plan is to integrate this into the transition, it will probably not 03:19.640 --> 03:22.200 work for Planet Terry's scale. 03:22.200 --> 03:28.720 So what I started was to do a very basic implementation of that that uses little resources 03:28.720 --> 03:32.760 and that has some chance to scale to that. 03:32.760 --> 03:41.040 So the algorithm is currently extremely easy and basic as soon as we receive a new position 03:41.040 --> 03:47.280 of a vehicle, we just remember that in memory for now and once the vehicle is close to 03:47.280 --> 03:52.160 a stop that we know where the time when it should stop there, we can tell whether the 03:52.160 --> 03:54.680 vehicles on time are not. 03:54.680 --> 03:58.960 If the vehicle is not on time because it has not arrived at the stop at the right time 03:59.040 --> 04:03.840 from the time-table, we can calculate difference between time-table and the current time 04:03.840 --> 04:09.120 and know the delay and if there is no delay, we can remember all the positions we had 04:09.120 --> 04:15.840 before and then we also can extend the time table with time and position pairs in between 04:15.840 --> 04:21.680 the stops so that once the vehicle runs again, we have some earlier predictions or earlier 04:21.680 --> 04:24.040 measurements at least. 04:24.040 --> 04:28.880 In practice that looks like this, we have some schedule, we have the actual real-time results 04:28.880 --> 04:33.040 and the difference between them is then the result. 04:33.040 --> 04:39.200 Once we have these measurements from punctual trips, we can add these just like the stops 04:39.200 --> 04:47.480 in between and then we can do the delay calculation as like a bit earlier. 04:47.480 --> 04:53.600 The result of that, we can then expose in GTFSRT trip update feed and that can be consumed 04:53.600 --> 04:59.360 by regular routing software that all of you are probably already using like motors or open trip 04:59.360 --> 05:01.360 planner. 05:01.360 --> 05:09.120 The idea is then that some application like BIMBA before can send a request like this with the 05:09.120 --> 05:17.840 GPS location of the device to an API that looks like this in my implementation and the 05:17.840 --> 05:24.240 two mentioned components then derive the delay from it and we get a proper delay in motors 05:24.240 --> 05:31.760 displayed for some train for example that does not have official delay information. 05:31.760 --> 05:36.960 The next step is to just get this deployed in production and implement it in a few apps so 05:36.960 --> 05:43.120 we can actually use it and then we can of course improve the very basic algorithm but for now 05:43.120 --> 05:57.840 this should work.