DevPost – Shepherd
The challenge that we decided to focus on revolved around utilising the WiFi data made available by BAI communications on the Toronto Rail Network. In specific individual devices connecting to access points within each station. From this data we were able to determine the route individual’s users (devices) were taking over the course of the week. This prompted us to investigate further into how we develop a system/solution or piece of software to work with staff at each of these rail stations. The solution began with ingesting the raw dataset’s and processing them through a python program to cleanse and categorise the dataset so that we would be able to map it out in a user friendly manner. The current UI would be accessible to station managers and easy to understand and navigate. It will allow them to understand typical journey patterns from their station, thus enhancing the speed and efficiency with which they are tackling any disruptions on their stations, such as an evacuation cause by a fire alert. Knowing the predicted destinations of customers on station at that point they can immediately distribute the crowd that has left their station toward the appropriate means of transportation, update the relevant station managers and service controllers about where the overspill is going to be felt; in a worst case scenario it would allow them to book targeted rail replacement services, thus diminishing the delay.
Products & services:
- Dashboard visualising customer flow data from a certain station based on historic data predictions;
- Adaptability across different rail networks, assuming WiFi data of similar quality to the Toronto sample used for this demonstrator.
- Better and more reliable information available to staff;
- Improved customer service in the post-disruption period;
- Increased efficiency in diminishing delays caused by station incidents by allowing better targeting of customer redistribution, hence reducing the number of lost customer hours;
- Using a sample of data about lost customer hours (LCH) from Transport for London (due to it being more accessible), 1.5mil LCH will cost the network approx. £13bn. To translate this into incidents and define time disruptions, this would be the rough equivalent of approx. 1,500 station closures (1,480 being the total number of station closures on the network in 2016/17) lasting around 6 minutes from stop to restart (a very optimistic estimation since most closures would cause larger delays). Assuming the return to travel of customers can be achieved 10% more efficiently, this would trigger significant savings
- Diminish the service disruptions caused by station incidents and hence improve overall station performance and customer satisfaction;
- Increase station staff efficiency by providing them with reliable information on travel trends and potential solutions.
Potential next steps and areas for future improvement:
- Integrate other live data sets with the existing feed to create a more complex and holistic picture of flow and factors that can influence disruption or make it worse (e.g. event data for neighbouring venues, weather, existing disruptions on alternative modes etc.);
- Introduce predictive ‘Warning’ features which could, based on historic data trends, prompt the dashboard to warn a supervisor of potential disruptions at neighbouring stations, thus allowing for preventive measures to be taken (for example, starting to shift customers to alternatives routes early so that congestion is eased);
- The generation of bespoke advice is also something worth exploring, since the dashboard data will be able to extrapolate the best solution for a particular situation based on what has worked well in similar past events.