project-proposal-2025

TranslinkLink

Abstract

TranslinkLink is a one-stop data source for public transport information, designed to accelerate development of passenger-facing displays—both physical signage and app/website views. Accurate, reliable, and up-to-date information is essential for a smooth public transport experience.

Broadly, TranslinkLink have two components: (1), a backend responsible for aggregating data from officially-provided feeds; and (2), multiple frontend modules which are purpose-built views of specific information (for example, station platform display or next stop displays). The backend will obtain its information from industry-standard sources (e.g., GTFS feeds), then make this data available through a documented and convenient API surface. The frontend views will render their displays by querying this API.

TranslinkLink has important non-functional requirements, arising from its vital role for public transport. These are: availability, the system must provide up-to-date information at all times; reliability, the system must detect and handle failures and disruptions to schedules; and interoperability, the system should support any public transport service with the appropriate data, and its back-/front-ends should should communicate with a well-defined API.

Assignment Links

Author

Name: Kait Lam

Student number: 45294583

Functionality

These are the features which would be delivered by a fully-completed project.

• Backend:
  • Support for fetching information from a large number of public transport agencies across the world.
  • Well-defined programming interface for easily integrating new public transport regions.
  • Support for all aspects of the GTFS (General Transit Feed Specification) data format, including static data (routes, stops, timetables) and dynamic data (vehicle positions, deviations and delays).
  • A public read-only API which reorganises and caches the information, making it available in a more convenient format. Some features:
    • Filtering responses by transport network, mode, time, platform, route.
  • Option for clients to subscribe to queries and receive push events when they change.
  • Published API specification with usage examples.
  • Error states and service updates returned alongside/instead of requested data where appropriate.
  • A management interface and account system for public transport agencies to modify their feed source and options.
  • A status page showing recent errors encountered when fetching data or when delivering data to clients.
• Frontend:
  • Multiple frontend views, each using a platform-appropriate format (e.g., HTML, image, or video), generated by querying the backend API. These could include:
    • Departure screen on platform — supporting both dot matrix and LCD screens.
    • Next stop display within train — supporting scrolling dot matrix and LCD screen.
    • Website view for travellers to see all active vehicles in the network, including smooth interpolation.
    • Views for analysis of the network, such as a heatmap to show high-throughput corridors.
    • Other views mimicking, as much as possible, the style of existing displays in Brisbane and around Australia.
  • Frontends designed with their use-case in mind. For example, a physical departure screen is a static view with fixed dimensions, but a smartphone view will need animations and interactivity.
  • For views designed for physical displays, these additional features:
    • Detecting and displaying error conditions (e.g., network error) and service updates (e.g., delays, cancellations).
    • Indicating whether an upcoming service is being tracked in real time, or if it’s merely a schedule.
    • Built with basic technologies to maximise compatibility. For example, simple HTML with little or no Javascript, or static images rendered on a server.

Related Work

Anytrip provides a number of views for AU/NZ transport services. There is no publicly-available API to build new frontends (however, some features are locked behind a subscription fee).

DVA5 (demo video) is a desktop application simulating platform displays of Sydney and Melbourne trains. Although it can fetch a GTFS from TransportNSW, this is hard-coded and difficult to extend. Additionally, being a monolithic Java GUI application, it is difficult to scale and integrate.

UQ SPlus display (archived) is a frontend view for room bookings at UQ, configurable with query params. (Note: the splus.uq.edu.au links can only be used from within the UQ network.)

Scope

The minimum viable product (MVP) will focus on Translink of south-east Queensland, Australia, because the familiarity will increase development speed. However, at least one interstate data source should also be present to ensure compatibility.

In the MVP, frontend views will be limited to:

• One kind of platform display, mimicking that at Translink busway stations.
• One kind of in-vehicle display, mimicking the Brisbane Metro display.
• One interactive online map showing all vehicles in the network, with filtering and searching features.

Additionally, the two physical display views should:

• support choosing different stations or routes (resp.),
• gracefully handle loss of connection, displaying this on-screen and retaining the previous information, and
• display basic service alerts (e.g., delays, cancellations).

Backend features in the MVP will be limited to those needed for implementing the listed frontends:

• A public API accessible with HTTP and with documentation (e.g., OpenAPI).
  • Only basic endpoints and filtering, as needed by the frontends.
• Fetching data from the defined GTFS feeds, extracting:
  • static stop and route information,
  • realtime vehicle timings and position,
  • scheduled services, and
  • basic service alerts and affected routes.

De-prioritised:

• Animations / position interpolation / smoothing.
• Pushing new data to clients—a polling fetch is an acceptable MVP.

Out of scope:

• Additional frontend views for transport network analysis.
• Management/admin interface to manage data feeds.
• User accounts for public transport agencies.
• Complex / non-routine service updates such as route diversions.

Quality Attributes

This project identifies these three quality attributes as the most important ones.

• Availability
  • The backend system must provide up-to-date information at all times of the day where public transport is running, especially in peak times. Even outside of operational hours, it is important to minimise downtime to show the first service of the next day.
  • The “all vehicles” map is a good test for the API efficiency under load, since it requires a large number of data points.
• Reliability
  • The end-user (passengers) must be able to rely on the frontend information being up-to-date and correct. They must be made aware when unexpected things happen (e.g., network error or service alert), so they know to seek other information or change their plans.
  • Both the backend and frontend should degrade gracefully—e.g., by returning old information when connection is lost, instead of only an error.
• Interoperability
  • The large number of public transport services—each with unique requirements—necessitates a interoperable design.
  • The system must support additional public transport agencies based on the same data feed format.
  • Additionally, it must be easy for ourself or third-party developers to create new frontend views.

Evaluation

This section describes how to evaluate whether the quality attributes have been achieved.

• Availability:
  • Extensive monitoring of production endpoints to obtain an uptime percentage metric and keep this above a certain threshold, with a particular focus on peak usage times.
  • Alerts configured based on response latency and error response codes, to allow detection when problems occur.
  • Stress testing based on anticipated worst-case load (as a ballpark estimate, 10,000 requests per second).
• Reliability:
  • Testing network errors by simulating disconnections and low bandwidth (e.g., using browser dev tools or automated tools), then ensuring the system responds appropriately.
    • Test individual failures of each component: GTFS feed, backend service, frontend service, and network errors.
  • Mock data containing cancelled or delayed services.
• Interoperability:
  • Code review to avoid special-cased behaviour.
  • Successful implementation of two GTFS feeds and three views will indicate some level of interoperability.
  • Auto-generating test API calls, based on the documented specification, to ensure the backend conforms to the API.