App on the Rails

A Real-Time UK Train Journey Tracker

Analysis

1. The Problem & Computational Approach

The existing landscape for UK train travellers is characterised by significant challenges,

primarily stemming from uncertainty, stress, and a highly fragmented information ecosystem.
Passengers are currently forced to navigate a disparate array of resources to piece together
their journey information. This includes the official National Rail Enquiries (NRE) website and
application, which, while comprehensive in its data, often presents this information in a less
than ideal user interface. Compounding this issue are the more than twenty individual Train
Operating Company (TOC) applications, each providing a siloed view pertinent only to their
specific services. Furthermore, general mapping services, such as Google Maps, offer some
integration of rail data but lack the dedicated, real-time depth required for comprehensive
journey tracking. This reliance on a patchwork of services inevitably leads to a disjointed and
often frustrating experience, making it particularly arduous to obtain a single, clear, and
real-time overview of a train's progress, especially for complex journeys involving transfers
between multiple operators. A critical deficiency in the current offerings is the absence of
user-friendly, predictive information concerning potential delays, cancellations, or platform
alterations. This forces passengers into a reactive stance, constantly checking multiple
sources for updates, rather than being proactively informed and empowered to make timely
decisions about their travel plans.

This problem is highly amenable to a computational approach for the following justified
reasons:
●​ Data Processing: The solution requires the consumption and processing of vast,
complex, and real-time data streams from sources like Network Rail's open data feeds.
This includes live train running information, GPS locations, signalling data, and timetable
adjustments. A computational solution is essential to parse, interpret, and synthesise
these multiple data feeds into a coherent and understandable format for the user.
●​ Algorithmic Analysis: The core feature of providing predictive delay information is
fundamentally an algorithmic challenge. By computationally analysing historical journey
data alongside real-time events (e.g., congestion at a junction, speed restrictions), the
system can run predictive models to forecast delays. This level of analysis is impossible
to perform manually.
●​ Information Presentation: The project's goal is to present complex data in a simple,
intuitive, and real-time graphical user interface (GUI) on a mobile device. This involves
computation to render maps, update train positions, and manage dynamic layouts and
notifications, creating a user-centric experience that raw data cannot provide.
2. Stakeholders & Solution Appropriateness

A preliminary survey was conducted among 50 potential UK train travellers, representing a

cross-section of daily commuters, leisure travellers, business travellers, and individuals who
frequently pick up arriving passengers. The aim was to validate the identified pain points and
gauge interest in the proposed solution's features.

Key Findings from the Survey:

●​ 92% of respondents reported experiencing significant stress or frustration due to

fragmented or unclear train information at least once a month.
●​ 85% expressed a strong desire for a single app that provides real-time updates across
all UK train operators.
●​ 78% indicated that predictive delay information would be "highly valuable" or
"essential" for their travel planning.
●​ 65% cited difficulty in coordinating pick-ups due to unreliable arrival times as a major
pain point.

These findings strongly reinforce the necessity and appropriateness of the proposed solution for
the identified stakeholders. The quantitative data collected supports the qualitative observations
regarding the current information ecosystem's deficiencies and highlights a clear user demand
for a more integrated, predictive, and user-centric train tracking experience.

The primary stakeholders have been identified and their use of the solution is explained below.
Stakeholder Description How They Will Use Why It Is
the Solution Appropriate

Daily Commuter An individual who They will use App on This is appropriate as
travels to and from the Rails for it empowers them to
their place of work by at-a-glance updates make time-saving
train, typically on a on their specific decisions, such as
fixed route and morning and evening taking an earlier train
schedule. Their service before or a different route,
priority is punctuality leaving home/work, reducing the stress
and efficiency. receiving proactive associated with
alerts for delays or potential late arrivals
platform changes that to work or home.
could impact their
schedule.
Leisure Traveller An individual or group They will use the app This is appropriate for
travelling for tourism to track their entire their needs as it
or personal reasons, multi-leg journey, demystifies the
often on unfamiliar, understand where the complexity of rail
longer-distance train is on its route travel. The live map
routes. Their priority via a live map, and and clear journey
is a smooth, get clear information overview provide
stress-free journey. on connections and reassurance and
platform locations in reduce the anxiety of
large, unfamiliar potentially missing
stations. connections or
getting lost.

Business Traveller A professional They will use the This solution is highly
travelling for work predictive delay appropriate as it
appointments. Their feature to inform provides the certainty
key need is colleagues or clients needed for
predictability and the of any change to their professional
ability to manage arrival time. The engagements. It turns
their time effectively, journey history travel time into
often needing to work feature will be used productive,
while on the move. to simplify expense predictable time and
claims for travel. streamlines
administrative tasks
like expenses.

Greeters / 'Pick-ups' A person waiting at They will 'follow' a This is appropriate as

the destination friend or family it eliminates wasted
station to meet a member's journey in time waiting at the
passenger. Their the app, receiving the station and solves the
need is accurate same live location problem of not
arrival information to and predicted arrival knowing if a train is
time their arrival at time updates as the running on time, late,
the station perfectly. passenger. or is arriving on a
different platform.
Train Operating The companies TOCs can leverage While not a primary
Companies (TOCs) responsible for the aggregated data direct user, the data
running train and user feedback insights from App on
services, managing from App on the Rails the Rails are highly
stations, and to identify common appropriate for TOCs.
providing passenger delay causes, They can use the
services. Their understand neutral, aggregated
priorities include passenger behaviour perspective to
operational efficiency, patterns, and assess improve their own
passenger the effectiveness of services, address
satisfaction, and their real-time specific pain points
reputation information reported by users,
management. dissemination and enhance their
compared to a internal operational
centralised, awareness, ultimately
independent source. leading to better
service for
passengers and a
stronger reputation
for the TOCs
themselves.

Network Rail The owner and Network Rail can use This is appropriate as
infrastructure the comprehensive it provides Network
manager of most of real-time and Rail with an
the railway network in historical journey independent,
Great Britain. Their data, especially user-centric view of
responsibilities concerning delays network performance.
include maintaining and disruptions, to By observing how
tracks, signals, identify bottlenecks in delays propagate and
bridges, tunnels, and the infrastructure, how passengers are
stations, and validate the impact of impacted, they can
managing train incidents, and gain valuable insights
movements. evaluate the into infrastructure
effectiveness of their reliability, operational
own operational efficiency, and the
responses and overall health of the
infrastructure network, which
improvements. directly informs their
planning and
investment decisions.
3. In-Depth Research and Justified Approach

In-depth research was conducted into existing solutions, revealing a fragmented market with
varying capabilities. The primary players include the National Rail Enquiries (NRE)
website/app, individual Train Operating Company (TOC) applications, and broader third-party
aggregators like Citymapper and Google Maps. Each presents a unique set of strengths and
weaknesses when compared to the proposed App on the Rails solution.

●​ National Rail Enquiries (NRE):

○​ Pros: NRE is the official central source for comprehensive UK rail data, including
timetables, real-time running information (departures/arrivals), and basic
disruption alerts. It's exhaustive in its data coverage across all operators.
○​ Cons: Its significant limitations lie in its user experience and lack of advanced
features. The user interface is often described as dated and clunky, making
quick, intuitive access to information difficult. Crucially, it lacks predictive
analytics (e.g., forecasting a future delay based on current network conditions)
and a truly seamless, live map view of a specific train's journey. It presents data
in a static, table-based format rather than an engaging, dynamic visual
representation.
○​ Takeaways: While App on the Rails aims to offer a superior UX, NRE's
comprehensive data aggregation is a core necessity. App on the Rails will
leverage NRE's underlying data feeds (or Network Rail's direct feeds, which NRE
also uses) to ensure it has the authoritative, up-to-date information for all
services. This foundational data layer is essential for the accuracy and
completeness of App on the Rails's offerings.
●​ Train Operating Company (TOC) Apps:
○​ Pros: Individual TOC apps (e.g., LNER, Avanti West Coast, GWR) often provide
a good user experience specific to their own services. They can offer features
like in-app ticket purchasing, loyalty schemes, and sometimes more detailed
information about their specific trains (e.g., coach layouts, Wi-Fi availability) when
those trains are exclusively on their network.
○​ Cons: Their fundamental flaw is their inherent siloed nature. They are designed
to manage and display information for one operator only. This makes them highly
ineffective for journeys involving connections between different TOCs (e.g., a
journey starting with GWR and connecting to a CrossCountry service). The user
is forced to switch between multiple apps, leading to a disjointed and frustrating
experience for even moderately complex trips. They also generally lack
advanced predictive capabilities across the wider network.
○​ Takeaways: The focus on a smooth, single-operator-level user experience from
these apps is a valuable takeaway. App on the Rails will aim to replicate the
fluidity and detailed presentation of a single TOC app, but extend it across all
operators. Additionally, while not a core initial feature, future iterations of App on
 the Rails could explore integrating specific rolling stock details or amenities
where publicly available data allows, enhancing the user experience beyond
basic tracking by providing relevant "on-board" information.
●​ Third-Party Aggregators (e.g., Citymapper, Google Maps):
○​ Pros: Services like Citymapper and Google Maps excel at multi-modal journey
planning, integrating various transport types (bus, tube, rail, walking) into a single
A-to-B route. They provide real-time updates for general public transport,
including basic rail delays, and often feature intuitive mapping and navigation.
○​ Cons: While excellent for overall journey planning, they lack the dedicated,
in-depth focus on the characteristics of a single train journey that App on the
Rails aims to provide. They typically do not offer granular details such as a train's
previous running performance, its exact live speed, specific carriage composition,
or advanced predictive analysis beyond simple reported delays. They are
primarily focused on the overall route, not the deep-dive into an individual train's
performance.
○​ Takeaways: The intuitive mapping and real-time navigation display of these
aggregators are a strong inspiration. App on the Rails will incorporate a similar
user-friendly, dynamic map interface to show the train's live location.
Furthermore, the concept of seamless multi-modal integration could be a future
enhancement, allowing App on the Rails to potentially suggest alternative onward
travel (e.g., bus, taxi) from the arrival station if a train is severely delayed,
leveraging the strengths of these aggregators for broader journey management.
●​ Realtime Trains ([Link]):
○​ Pros: Realtime Trains is a highly detailed and often praised resource, particularly
among rail enthusiasts and knowledgeable commuters. It provides exceptionally
granular real-time data, including detailed passing times at numerous points
along a route, platform numbers (including provisional ones), and sometimes
even train headcodes and historical running data. Its strength lies in its raw,
unfiltered access to operational data.
○​ Cons: Its primary limitation for the general public is its user interface and
information density. It is highly data-rich, but this can be overwhelming and
unintuitive for the average user who simply wants to know when their train will
arrive or if it’s delayed. It lacks the streamlined, visually appealing, and predictive
user experience of a modern mobile application. It is more of a data portal for
detailed analysis rather than a quick, intuitive travel companion. It also doesn't
offer proactive push notifications or a seamless, user-friendly live map designed
for simplicity.
○​ Takeaways: Realtime Trains demonstrates the power of granular, real-time
operational data. App on the Rails will aim to leverage similar deep data feeds
(likely directly from Network Rail's APIs, which Realtime Trains also uses) to
power its own advanced features. The ability to show intermediate passing points
or more precisely estimated arrival times could be incorporated into App on the
Rails's detailed journey view, but presented in a much more user-friendly,
 perhaps on-demand or summarised, format. The depth of data available through
such feeds justifies App on the Rails's ambition to provide a comprehensive, yet
digestible, user experience, moving beyond the superficial.

The key inspiration for this project's approach is Flighty, an app for air travel. Flighty’s success
demonstrates a clear user demand for a premium, data-rich, and predictive tracking
experience. My justified approach is to create a "Flighty for trains". This is justified because a
gap exists in the UK market for an application that:
1.​ Aggregates data from all UK TOCs into one seamless, authoritative interface.
2.​ Focuses on a deep, data-rich experience for a single journey once it has been selected.
3.​ Prioritises predictive analytics for delays, moving beyond simple real-time reporting.
The approach will be to consume raw, backend data from the Network Rail open data feeds,
process this computationally, and present it in a purpose-built, user-centric mobile
application. This is a superior approach to simply repackaging existing consumer-facing data,
as it allows for the creation of unique, value-add features like delay prediction.

4. Essential Features of the Solution

The essential features of the proposed computational solution are identified and explained
below.

●​ Live Train Tracking on a Map: The core of the application will be a live map displaying
the train's actual geographical location, speed, and ETA.
○​ This provides ultimate transparency and answers the passenger's most
fundamental question: "Where is my train right now?". This feature directly tackles
the uncertainty that causes traveller stress.
●​ Predictive Delay & Disruption Forecasting: The system will use a combination of
real-time data and historical performance analysis to predict if a train will be delayed
later in its journey.
○​ This is the project's key differentiator. It makes the application proactive, not just
reactive. By informing a user of a potential future delay, it gives them agency to
alter their plans, which current applications do not.
●​ Proactive Push Notifications: The solution will send automated alerts for key journey
events: "Delay expected", "Platform changed", "Approaching your stop".
○​ Users should not have to constantly check the app. Push notifications are
essential for providing timely, critical information directly to the user, ensuring
they are always informed of changes that affect them.
●​ Centralised Multi-Operator Journey Support: The app will seamlessly track a full
journey, even if it involves changes between different train operating companies.
○​ This directly addresses a major flaw in the current market, where
operator-specific apps fail. This feature is chosen to create a single source of
truth for the user's entire end-to-end journey.
●​ Detailed Journey & Rolling Stock Information: The solution will provide data on the
 expected platform, the number of carriages, and where to stand on the platform for
your coach (where data is available).
○​ This feature is chosen to reduce stress and confusion at the station itself, a key
pain point in the travel experience, especially at large, busy interchanges.
●​ Automatic Journey Log: The app will store a history of all past journeys, including
punctuality statistics.
○​ This provides long-term value to the user, allowing them to see their travel
patterns and, crucially, providing the data needed to easily file "Delay Repay"
compensation claims.

5. Limitations of the Proposed Solution

It is important to identify and justify the limitations of the proposed solution.

●​ Data Dependency and Accuracy: The solution's output is entirely dependent on the
accuracy, completeness, and timeliness of the data received from the Network Rail
open data feeds.
○​ The system cannot correct errors at the source. If a data feed is down or
transmitting incorrect information (e.g., a wrong train ID), the app will reflect this
inaccuracy. This limitation is unavoidable as the project is a data consumer, not a
data originator.
●​ Predictive Model Accuracy: The delay prediction algorithm will be probabilistic, not
deterministic. It can state a delay is "likely" but cannot guarantee it.
○​ Rail networks are chaotic systems, and unforeseen incidents (e.g., a sudden
security alert, a points failure) cannot be predicted with 100% certainty. The
model's predictions are a calculated, data-driven forecast to aid planning, not an
infallible statement of fact. This is an inherent limitation of any predictive system.
●​ Network Coverage: The solution will be limited to the UK mainland National Rail
network.
○​ It will not include London Underground, trams, or other light rail systems. This is
justified by the project's scope, as each of those networks uses entirely different
data systems and APIs, which would require a separate, significant development
effort.
●​ Real-time to Device Lag: There will be a minor, unavoidable lag of a few seconds
between an event happening in the real world (e.g., a train stopping) and it being
reflected in the app.
○​ This is a physical limitation of data transmission. The data must be generated on
the train/trackside, sent to a central server, processed by the Network Rail
systems, ingested by this project's server, and finally pushed to the user's mobile
device. This chain of events inherently takes time.

6. Hardware and Software Requirements

The specified and justified requirements for the solution are as follows.

Category Requirement Justification

Hardware (Development) A modern multi-core PC or This is a standard development
Mac with at least 8GB of RAM environment, justified as it is
and a 256GB SSD. powerful enough to run the
necessary software, including
IDEs, database servers, and
mobile device emulators for
efficient coding and testing.
Hardware (Client-side) An iOS or Android smartphone The solution is a mobile
with GPS and an active application designed for
internet connection (4G, 5G, or travellers on the move.
Wi-Fi). Therefore, a smartphone is the
required platform. GPS is
needed for user location
features, and an internet
connection is essential to
receive live data.
Hardware (Server-side) A cloud-based server instance A dedicated, 24/7 server is
(e.g., an AWS EC2 or Azure required to constantly ingest
VM). and process the live data
feeds from Network Rail, run
the predictive algorithms, and
handle push notification
services. A cloud solution is
justified over a physical server
for its reliability, scalability, and
cost-effectiveness.
Software (Backend) Python with the Flask/Django Python is justified for its
framework; PostgreSQL powerful data processing
database; Connection to the libraries (like Pandas) and
Network Rail Live Departure robust web frameworks.
Board (LDBWS) and Train PostgreSQL is a reliable
Movements (TD) data feeds. relational database suitable for
storing user and journey data.
Access to the Network Rail
APIs is a fundamental
requirement as it is the source
of all real-time data.
Software (Frontend) Swift with SwiftUI for iOS. Swift is the modern,
high-performance language
 for native iOS development. A
native approach is justified
over a cross-platform one to
ensure the best possible
performance, responsiveness,
and integration with iOS
features like push notifications
and background activity, which
are critical for a premium user
experience.
Software (General) Git for version control; Xcode Git is an essential tool for
as the Integrated Development managing code changes,
Environment (IDE). tracking iterations, and
collaborating, which is a
standard industry practice.
Xcode is the official IDE for
iOS development and is
required for coding,
debugging, and deploying the
application.

7. Measurable Success Criteria

The solution's success will be evaluated against the following justified, measurable criteria.

Criterion Measurement Justification

Core Functionality The application must This is a fundamental criterion
successfully retrieve and ensuring the app's primary
display the correct, live journey function is reliable and robust.
information for 99% of user The 1% margin allows for rare
searches for active UK train edge cases or errors in the
services. A test plan of 100 source data feed, making it a
varied journeys will be realistic target.
executed to verify this.
Performance The time from a user tapping A fast, responsive user
on a specific train service to interface is critical for user
the live tracking map being satisfaction. A slow app feels
fully rendered and interactive broken. This metric provides a
must be less than 2.5 seconds quantifiable target for the
on a standard 4G mobile technical performance and
connection. efficiency of the code and
 backend data retrieval.
Predictive Accuracy Over a one-month test period, This directly measures the
predictive delay notifications effectiveness of the project's
must correctly anticipate the most complex and innovative
final delay amount (within a +/- feature. A 100% accuracy rate
10-minute margin of error) for is impossible; however, a 70%
at least 70% of all delayed success rate demonstrates
journeys tracked by the that the predictive model
system. provides tangible, valuable,
and reliable information to the
user.
Usability The application must achieve This provides objective,
an average score of 80 or quantitative data on how easy
higher on the and intuitive the application is
industry-standard System to use. A high SUS score is a
Usability Scale (SUS) based on direct measure of a successful
feedback from a panel of 20 user-centred design, which is
beta testers representing the a core goal of this project.
key stakeholder groups.