← all projects

Melbourne Trams Location Dashboard

Melbourne trams location dashboard

Melbourne's tram network has long relied on signpost beacons positioned along the route corridors as its primary source of vehicle location — each tram reports a proximity event as it passes a beacon, which is cross-referenced against a geospatial reference file containing the surveyed location, route chainage and orientation of every beacon on the network. The existing tracking tool built on this data was an ageing desktop application, and the project was to replace it with a real-time web dashboard.

Around the same time, a GPS trial was rolled out to a small subset of six trams, giving a secondary, continuous position source to overlay against the beacon-derived locations for that handful of vehicles.

Architecture

The system was built on Azure:

  • Event Hub ingested the live beacon and GPS telemetry streams from the network.
  • Stream Analytics processed those events in near real-time — cross-referencing beacon events against the geospatial reference file to resolve them to a track position, and merging in GPS readings for the trial trams.
  • .NET Core services sat behind this, handling business logic and state.
  • SignalR pushed live position updates out to connected clients so the dashboard updated in real time without polling.
  • The frontend was built in plain JavaScript, rendering tram positions over the network map as updates arrived over the SignalR connection.

The scale of the geospatial data

The geospatial reference file wasn't a small lookup table — it captured the exact GPS coordinate of every metre of track across the entire network. Picture a spreadsheet with a row for every single metre of tram line in Melbourne: hundreds of thousands of rows, each needing to be cross-referenced against incoming beacon and GPS events for every tram, in real time, simultaneously across the whole fleet. Processing that volume of lookups fast enough to keep the dashboard feeling "live" — rather than lagging seconds or minutes behind reality — was one of the harder engineering problems on the project, and it shaped a lot of the decisions around how data flowed through Event Hub and Stream Analytics rather than being resolved with naive point-in-time queries against the full file.

A one-channel radio problem

One of the more interesting quirks came from the trams' communications hardware: each vehicle only had a single channel available to send data. If a driver was using that channel to talk to another driver over the radio, location data physically couldn't be transmitted at the same time. From the dashboard's point of view, a tram would appear stuck in one spot for a while and then jump to somewhere else in the city once the driver had finished their conversation and the channel freed up — rather than moving smoothly along its route. Understanding this behaviour was important for setting expectations with users of the tool, since it looked like a data fault but was actually a hardware/communications constraint inherent to the fleet at the time.

Traffic light integration

The system also integrated with Melbourne's traffic light network to actively influence signal timing based on real-time schedule adherence, rather than just observing it. Using the corrected track position for each tram, the app compared actual progress against the timetable and could request a light change at an upcoming intersection: asking for a red if the tram was running ahead of schedule, holding it back briefly, or asking for a green if it was running behind, letting it through without stopping. That turned the location data from a purely informational feed into an input for actively keeping trams on schedule across the network.

Outcome

The result was a real-time, web-based replacement for the legacy desktop tool — giving operators a live view of tram positions across the network derived primarily from signpost beacon data, with GPS overlay for the trial vehicles and active traffic light integration to help keep services on schedule, all delivered through an Azure Event Hub / Stream Analytics / SignalR pipeline to a lightweight JavaScript frontend.

Matthew Ratcliffe, software developer and architect, Ballarat
Senior Software Engineer & Architect

20+ years across the technology stack — from greenfield builds to brownfield rescues. Based in Ballarat, VIC, focused on AI, healthcare and high-risk data systems. Full resume →