Statistics / Forecasting
Pickup Alerts for FlySafair
Telling the person fetching a passenger when to leave, not just when the flight lands
A proposed add-on for FlySafair bookings. The passenger ticks Pickup alerts, and the person fetching them gets WhatsApp messages with the time to leave home. The time combines where the aircraft is, how late its earlier legs are running, the walk to the kerb and the drive in traffic, and it is chosen so the passenger is rarely left waiting outside.
0.2%
Passengers waiting over 5 min, with alerts
5.5%
The same, leaving for the usual time
3 min
Average landing error an hour out
474 arrivals into Johannesburg and Cape Town, 11 to 17 October 2026, each day predicted from a model built on the other days. The 1 h error uses the airline's own take-off times.
Live follows today's FlySafair arrivals into O.R. Tambo and Cape Town, updated every three minutes. Search for any place to leave from and the drive comes from Google in current or forecast traffic. Replay steps through a real flight from the test week; Accuracy shows the backtest.
Problem
Airlines tell the passenger about delays, but the person collecting them is left to watch a flight tracker and guess. Leave for the scheduled time and they either wait in the pickup lane or, worse, the passenger stands outside with their bags. A delay notice also arrives too late to help if it only goes out once the departure board changes. The useful number is not the landing time but the time to leave home.
What I built
Every FlySafair aircraft is followed through its day from open ADS-B data, so a delay on an earlier leg is visible hours before the flight in question. The engine predicts the landing time with a spread, adds taxi-in, the walk out and the carousel, and picks the moment to arrive at the kerb by weighing a minute the passenger waits as two minutes the driver waits. It then subtracts the drive from wherever the driver is, using Google's traffic-aware routing for that time of day. Messages follow a fixed rhythm: one plan in the morning, an update only when the time to leave moves by ten minutes or more, a 30-minute heads-up, leave now, and landed.
Methods
- Legs reconstructed from each aircraft's ADS-B trace: landings, take-offs and stops hidden in receiver coverage gaps, which are inferred from heading and flying time and marked as estimated
- Before the aircraft flies, the flight is expected at its usual time: the median take-off for that flight number on other days plus the usual flying time for the route
- Delay carried forward along the rotation: a leg cannot take off before its usual time, nor before the aircraft has landed from its previous leg and had its shortest practical turnaround at that airport
- Once airborne, the remaining time comes from distance to go, using how long FlySafair aircraft at that distance took on other days
- Prediction intervals from how wrong the engine was at the same lead time on other days; the target is the point where the passenger is out early only one time in three
- Drive time from Google Routes in 15-minute slots: current traffic for the slot under way, predicted traffic for later today, and the same weekday and time next week for slots already past
- Leave-one-day-out backtest scoring only Johannesburg and Cape Town arrivals, where receivers see the landing itself, against two baselines: leaving for the usual landing time, and following delay notices
Technical architecture
- Batch pipeline in Python turns a week of adsb.lol archives into legs, fits the engine and writes the replay and backtest as JSON
- A Lambda polls adsb.lol every three minutes during the flying day, updates every aircraft's legs and writes one file of predictions for today's flights; the morning schedule comes from AeroDataBox
- A second Lambda proxies Google Places search and Routes drive times, so the API key never reaches the browser; requests are limited to the site's origin and cached per 15-minute slot
- Static dashboard on S3 and CloudFront, embedded here and usable on its own
Results
- Two hours before landing the engine is out by 8 minutes on average, against 9 for the usual time. The gain comes from seeing earlier legs run late before the flight is even boarding
- An hour out, with the airline's own take-off times, the error falls to 3 minutes, against 4 for delay notices. From public ADS-B alone it is 5, because receivers rarely see take-offs at the smaller airports and the aircraft is first heard about half an hour after leaving
- With alerts, 0.2% of passengers waited outside for more than 5 minutes, against 5.5% when the driver left for the usual time and 0.4% when following delay notices
- The driver's median wait at the kerb fell from 7 minutes to 3.5
Research context
- One week of open data. A real service would learn from a full season and use the airline's own schedule, aircraft assignments and ground handling times, which replace the parts reconstructed here.
- The backtest treats the drive as known, so on-the-day traffic surprises would add to the waits shown. Taxi-in, walking and carousel times are declared assumptions because ADS-B does not see them.
- Privacy: the person fetching opts in on WhatsApp before anything else is sent, because under POPIA the passenger's consent does not cover a third party. Their location is used only for the drive and deleted after landing. The demo uses public landmarks, and a place searched on the dashboard is not stored.
Technology
- Python
- pandas
- ADS-B (adsb.lol, OpenSky)
- AeroDataBox
- Google Routes API
- Google Places API
- AWS Lambda
- S3 and CloudFront
- SVG charts