The operator publishes data
Operators or their technology suppliers publish schedules and automatic vehicle-location updates.
Independent travel information
Where the timetable and live vehicle information comes from, how we turn it into departure predictions, and why it may occasionally differ from information supplied by the operator.
Return to the bus mapThis website is independently operated and is not affiliated with, endorsed by, or operated by Brighton & Hove Buses, Metrobus, the Department for Transport or the Bus Open Data Service. For official travel advice, service updates, tickets and customer support, please use the relevant bus operator’s website.
The main source is the Department for Transport’s Bus Open Data Service, usually shortened to BODS.
BODS makes timetable, route, fare and vehicle-location information published by bus operators available as open data. We currently use the timetable and vehicle-location parts of that service.
Operators or their technology suppliers publish schedules and automatic vehicle-location updates.
The Department for Transport makes the information available through open datasets and live feeds.
Our server imports the schedules, matches live vehicles to trips and produces the map and departure boards.
These times show when this website last completed a successful refresh of each type of public information. They do not necessarily represent the time of the operator’s most recent change.
Latest successful processing of published vehicle information.
2 seconds agoLatest successful publication of timetable information.
14 hours agoLatest successful refresh of stop names, indicators and locations.
5 days agoLatest successful refresh of vehicle names, registrations and ages.
3 days agoA missing time does not prevent the map or departure boards from working. It usually means the relevant information has not completed its first refresh since freshness reporting was enabled.
Published timetable data describes routes, stops, trips, service calendars, stop sequences and scheduled departure times. We import this into local GTFS-style tables used by the website.
This gives us the planned order of stops for each individual trip, rather than assuming that every journey on a route follows exactly the same pattern. This matters because a route may have:
Route lines shown on the map are generated from the published route shapes. Where a route has several legitimate variants, the map can display more than one shape.
Vehicle positions are obtained from the BODS SIRI-VM feed. SIRI-VM is a standard format for sharing automatic vehicle-location information between transport systems.
A live record can contain information such as:
A position is the latest observation received from the vehicle. It is not necessarily its exact location at the moment the map is viewed. Feed, network and processing delays can all make a marker appear behind the real bus.
There is an extra hand-off between a bus reporting its position and that position reaching this website. Operators and their tracking suppliers may have access to their own lower-latency vehicle tracking systems. The public copy has to be published through BODS and then collected and processed by us, so it can be a little older by the time it reaches the map or a departure board.
That means an operator’s own app, control room or stop display may sometimes show a bus a few seconds further along the road, or update an arrival before we do. We cannot see the operator’s private live feed; we can only work with the latest public BODS observation we have received. Our prediction code can estimate movement between observations, but it cannot turn an older observation into a truly instant location.
A location alone is not enough to identify a journey. Two buses may be close together, travelling in opposite directions, or serving different branches of the same route.
We therefore compare several pieces of information, including:
If the evidence is not strong enough, we prefer not to claim that a vehicle serves a particular stop. This may mean that a genuine bus is temporarily absent rather than shown on the wrong side of the road or against the wrong journey.
Live feeds can occasionally contain school-only, positioning or otherwise non-public journeys using a familiar route number. Confirmed examples can be excluded using their exact route, origin and destination references. We do not broadly hide every journey that mentions a school, because many ordinary public services legitimately serve schools and colleges.
The timetable is our starting point, but a live bus is rarely running exactly to it. When a recent vehicle position can be matched to a particular journey, we use that journey’s stop order and route shape to work out how far the bus has actually got.
We then compare its observed progress with where the timetable says it should be. Stops that the bus has already passed are removed, and the remaining times are adjusted from that live position.
When the bus is reasonably close to a stop, we can also use its recent movement to improve the estimate. We look at several recent observations rather than trusting a single GPS jump, and ignore readings that are stale or imply an unrealistic speed.
This is most useful over the last part of a journey to a stop, where the timetable alone cannot tell us whether the bus is moving freely, crawling in traffic or waiting at lights.
We keep recent observations of how long buses actually took to travel between neighbouring stops. Where there is enough good data, we use journeys from a similar day and time of day to help estimate the road ahead. A weekday morning, for example, is treated differently from a quiet Sunday afternoon.
For each section we use the middle of the recent observations rather than a simple average. That makes the result less likely to be thrown off by one unusually slow journey, a long wait at a stop or a bad location reading. Samples that do not meet the quality checks are not used.
These historical timings do not take over from the live position. They are a limited adjustment to the live estimate. If there is not enough reliable history for part of the route, the published timetable is still used for that section.
In practice a live time can therefore use several pieces of evidence at once: the timetable, the bus’s current position, its recent movement and, where there is enough evidence, recent real-world travel times over the road ahead. The balance changes as the bus gets closer.
Predictions are recalculated regularly and cached briefly so every visitor does not have to process the complete live feed separately. The displayed time is still an estimate rather than a guarantee that the bus will arrive at that exact minute.
We have matched a recent vehicle observation to this particular timetable journey and calculated a prediction from its progress.
The time comes from the published timetable because no sufficiently reliable live vehicle match is currently available.
“Scheduled” does not necessarily mean that the bus is cancelled or not running. It only means that this website cannot currently attach a reliable live observation to that departure.
The browser uses MapLibre to display route lines, stops and vehicle markers over OpenStreetMap-based mapping.
Static information—such as stops and route shapes—is generated periodically and served as GeoJSON. Frequently changing vehicle and departure information is prepared by a background task and stored in a short-lived cache.
Between live observations, a marker may be moved along the matched route shape to make movement easier to follow. We limit how far a position can be corrected. If an observation is too far away from the expected route, the site avoids drawing an invented straight line across buildings or unrelated roads.
When a bus marker is selected, its popup uses the matched trip’s remaining ordered stops. Passenger-facing destinations prefer a curated route mapping where one is available, followed by the matched trip’s final stop. Timetable and live-feed names are used only as fallbacks. This keeps ordinary termini consistent while still preserving branches and short workings.
Open transport data is extremely useful, but it is not perfect. Information may occasionally be late, incomplete, contradictory or attached to the wrong journey.
Examples include:
Please allow extra time for important journeys and check official operator information for disruptions, cancellations, accessibility, fares and ticket validity.
| Information | Source or process |
|---|---|
| Timetables | Operator-published open timetable data imported locally |
| Vehicle locations | Public BODS SIRI-VM feed; this can be slightly behind an operator’s own lower-latency tracking systems |
| Stops and stop order | Imported timetable and stop-time records |
| Route lines | Published route shapes converted into GeoJSON |
| Live predictions | Timetable baseline refined by matched live progress, recent movement and reliable historical stop-to-stop timings |
| Historical timing | Recent good-quality observed travel times between neighbouring stops, weighted towards a similar day and time |
| Scheduled predictions | Future calls from the active timetable calendar |
| Destinations | Curated route naming, then the matched trip’s final stop, with timetable and live-feed fallbacks |
| Map rendering | MapLibre with OpenStreetMap-based mapping |
| Performance | Background processing, static GeoJSON and short-lived Laravel caches |