How to translate GTFS Realtime Trip Updates, bus and train arrival predictions, delays and cancellations correctly: keep the trip identity, scheduled stop sequence, prediction timestamp, delay unit, stop-level status and trip-level service status distinct before drafting passenger-facing wording. Whether you searched for GTFS Realtime translation, GTFS TripUpdate explained, transit delay data localisation, real-time bus arrival information, `stop_time_update` interpretation, `SKIPPED` versus `CANCELED` or public transport prediction accuracy, the essential rule is the same: a missing prediction is not evidence of an on-time service, and a skipped stop is not automatically a cancelled journey.
GTFS Realtime is a standard for exchanging transport updates that complement a scheduled GTFS dataset. Its TripUpdate messages describe predicted arrival and departure times, relative delay, stop changes and selected trip-level relationships. An app may render that information as ‘5 minutes late’, ‘not stopping here’, or ‘trip cancelled’. Those phrases have different evidentiary meanings. A fluent translation can still be wrong if it changes the sign of a delay, treats a raw time as a local clock, converts a stop omission into a whole-service cancellation, or describes the lack of a feed record as proof of punctuality.
This practical, world-facing guide is about translating the semantics of structured GTFS Realtime TripUpdate records and making them intelligible to editors, developers, data journalists, language learners, transport-information teams and passengers. The official Trip Updates documentation and GTFS Realtime reference define the key message relationships, while GTFS Realtime best practices explain freshness and producer conventions. The guide does not claim to operate any transport service, predict today’s journeys or replace an operator’s official live notice.
The answer: translate the data state before the passenger sentence
Freeze a feed snapshot and its retrieval time; identify the linked schedule and trip instance; separate trip-wide `schedule_relationship` from stop-specific `schedule_relationship`; examine `arrival` and `departure` predictions with their actual seconds and epochs; preserve the stop order; distinguish fresh predictions, absent predictions and explicit `NO_DATA`; then write reader-friendly language that is never stronger than the data. The final test is whether an independent reader could reconstruct the same scheduled journey, stop status, time difference and certainty using the translation alone.
Three examples show the boundary. First, a `delay` of `300` in a compatible TripUpdate means five minutes behind the schedule, not 300 minutes; a `delay` of `-120` indicates two minutes ahead, not two minutes late. Second, `SKIPPED` for one `StopTimeUpdate` identifies a stop the trip will not serve, whereas trip-level `CANCELED` applies to the trip. Third, when a scheduled trip has no corresponding TripUpdate, the specification says real-time prediction information is absent; one cannot infer that the trip is running exactly on time. These are small symbols with large consequences in translation.
The canonical job of this page is deliberately narrow. A different eduKateSG article explains GTFS `translations.txt` for static multilingual stop and route names. Another explains public transport route maps and passenger timetables more broadly. This article is about the realtime update record: signed delay, propagated predictions, timestamp freshness, `NO_DATA`, `SKIPPED`, `CANCELED`, and the difference between data missing and service not running. Keeping those jobs apart prevents search-intent cannibalisation and helps each article answer a specific reader question.
The visible problem: an arrival board can lie without changing any digits
Suppose a route is scheduled to reach a stop at 14:10. Its realtime feed gives an arrival `delay` of `300` seconds. A translation system copies the numeral but calls it ‘300 minutes delayed’. Another system notices that one intermediate stop has status `SKIPPED` and announces that the entire route is cancelled. A third sees no TripUpdate at all and assures people that the bus is on schedule. None of those statements is supported by the data, even though each could be presented in impeccable grammar.
The deeper difficulty is that GTFS Realtime is not simply a bag of text strings. It is structured, time-sensitive information that depends on a matching static schedule and on the relationships between successive update fields. One stop may have a prediction, the next may inherit a delay, a third may have `NO_DATA`, and a fourth may be explicitly skipped. The translation must respect this chain. Replacing all four states with ‘late’ or ‘not running’ erases precisely the information an arrival app needs.
Passenger communication adds a second risk. A predicted arrival of 14:15 can be useful, but it is not an unconditional guarantee that a bus will be at the stop at 14:15. A correct educational or public-information translation can call it an estimate or prediction and show when it was updated. The raw feed may be stale, its schedule link ambiguous, or its original status field unknown. The translator’s proper role is to make those limitations understandable, not hide them to produce a friendlier headline.
First principles: the exact meaning of each realtime field
1. A TripUpdate belongs to a particular trip instance
A GTFS trip normally represents a defined sequence of stops and timing for an instance of service. The realtime `TripDescriptor` identifies the trip the update concerns. Its fields can include `trip_id`, `start_date` and `start_time`, with relevance depending on the service and schedule relationship.
What goes wrong: ‘The 8:15 departure’ may be ambiguous when routes repeat, services run overnight or multiple trips share a headsign. Verification rule: Preserve the identifiers as keys. Explain a route name or destination only after matching the correct schedule and trip instance.
2. A route and a trip are not equivalent
A route can have many scheduled trips, directions and service patterns. One `CANCELED` TripUpdate does not establish that every trip on its route has been cancelled.
What goes wrong: ‘Route 24 is cancelled for the day’ is broader than an update affecting a single identified journey. Verification rule: Use trip-specific language unless the source service alert or authoritative notice explicitly applies to all route service.
3. Static schedule and realtime prediction do different jobs
GTFS Schedule gives planned stops and times; TripUpdates add actual or forecast deviations where data are available. Neither may be described accurately without knowing which layer a value came from.
What goes wrong: A scheduled arrival printed in a timetable can look exactly like a realtime prediction if provenance is not labelled. Verification rule: Mark the source of each displayed clock time as scheduled, predicted, actual or unavailable.
4. An absent TripUpdate does not mean a service is on time
The official GTFS Realtime guide explicitly says that no update for a scheduled trip means realtime information is unavailable, not that the trip is necessarily following its schedule.
What goes wrong: A consumer app that inserts ‘on time’ for a missing entity asserts a status the producer did not provide. Verification rule: Translate missingness as ‘no realtime prediction available’ or equivalent wording, not a punctuality claim.
5. Delay is a signed number in seconds
For the specified delay fields, a positive value means behind schedule and a negative value means ahead. Zero indicates no deviation in that context. The standard unit is seconds, even when an interface displays minutes.
What goes wrong: `-120` becoming ‘120 minutes late’ loses both sign and unit, while `300` becoming ‘300 minutes’ exaggerates a five-minute delay. Verification rule: Verify sign, unit and whether the value is associated with arrival, departure or trip-level deviation.
6. Absolute time and relative delay are alternative descriptions
A `StopTimeEvent` may give an absolute predicted `time`, a relative `delay`, or both under applicable rules. A relative delay needs a scheduled time for interpretation; an absolute timestamp encodes a particular instant.
What goes wrong: Adding delay to a time that is already a predicted epoch double counts the delay and creates a fictional arrival. Verification rule: Keep the time representation explicit; if both fields exist, follow the specification’s priority and inspect consistency.
7. Epoch timestamps are not local wall-clock strings
GTFS Realtime event times and timestamps use POSIX seconds relative to the Unix epoch, not a number such as 1415 that can be read as 14:15. Conversion requires a time-zone-aware clock and the correct service context.
What goes wrong: An app that interprets epoch seconds as minutes since midnight can place vehicles in the wrong day or even year. Verification rule: Preserve the raw timestamp for audit and label any converted date, local zone and daylight-saving context.
8. Prediction freshness influences what an arrival statement can claim
A TripUpdate may include a timestamp indicating when its prediction was updated, and a FeedHeader also carries timing context. A prediction from an old snapshot should not be described as a current measured position simply because the article is being read now.
What goes wrong: ‘The bus is five minutes away right now’ may have been based on a feed that had not refreshed for many minutes. Verification rule: Keep the producer timestamp, retrieval time and update-age meaning distinct. The official best-practices document specifies freshness recommendations.
9. Arrival and departure are not one field
A `StopTimeUpdate` can include both `arrival` and `departure`. When vehicles stop or dwell, the arrival and departure instants can differ.
What goes wrong: Translating a departure prediction as the moment a vehicle arrives could tell passengers to reach a platform after the boarding opportunity. Verification rule: Identify which of the two events a clock or delay belongs to and retain its label in both table and summary.
10. A stop ID is not a translated stop name
`stop_id` connects an update to the schedule’s stop record. A passenger-facing place name may be localised, but the ID remains a stable machine reference.
What goes wrong: Changing an ID to its translated display name can break the join with `stops.txt` or point at another stop with a similar name. Verification rule: Keep `stop_id` unchanged, resolve a display name through authoritative static schedule data, and use `translations.txt` for appropriate translated labels.
11. Stop sequence defines order, not a continuous count
`stop_sequence` places records in the journey order. Its values need not be consecutive integers. A trip can also visit the same stop more than once, making sequence crucial to disambiguation.
What goes wrong: A translator may assume that missing sequence number 4 means stop 4 was cancelled, though it may not exist in the schedule data at all. Verification rule: Match sequence values against `stop_times.txt`; never manufacture missing stops from gaps in numbering.
12. A StopTimeUpdate can influence subsequent stops
Under the specification, a delay at a specified stop may propagate to later scheduled stops until overridden by an appropriate later update. A sparse update does not necessarily mean only one stop is affected.
What goes wrong: A summary that limits the five-minute delay to the first listed stop can contradict the rules used by a timetable consumer. Verification rule: Interpret the whole sequence and apply specified propagation rules before wording the effects of an update.
13. SKIPPED applies to the stop, not necessarily the trip
A stop-level `SKIPPED` relationship means the trip will not stop at that particular stop. It does not by itself mean all following stops are cancelled, and under the official guide it does not stop delay propagation.
What goes wrong: ‘This bus trip is cancelled’ is unsupported if only one intermediate stop was explicitly skipped. Verification rule: Use ‘will not stop at [stop]’ for that stop, keeping the trip identity and other stop statuses separate.
14. NO_DATA marks absence of stop prediction
A stop-level `NO_DATA` relationship says the feed has no realtime prediction information for the affected stop context. Under documented propagation rules it stops the carried-forward delay from continuing beyond that point.
What goes wrong: ‘No service to this stop’ confuses missing prediction with operational cancellation. Verification rule: Use ‘realtime arrival data not available’ rather than ‘the service is not running’, unless other authoritative evidence says otherwise.
15. CANCELED is a trip-level relationship
When `TripDescriptor.schedule_relationship` is `CANCELED`, the identified trip is cancelled. This is distinct from a single skipped stop or an absent TripUpdate record.
What goes wrong: A service interruption headline that expands one cancelled journey into a whole-line shutdown is misleading. Verification rule: Keep the scope trip-specific and preserve service date, trip identifier and update version in the explanation.
16. A trip status can override detailed stop entries
The specification gives precedence to trip-level cancelled or deleted status over stop-specific prediction details when both appear. A translator cannot cherry-pick a future stop time and present a cancelled trip as operating.
What goes wrong: ‘Expected at 14:15’ may be wrong when the same TripUpdate indicates the entire trip is cancelled. Verification rule: Resolve trip-level status before rendering any subordinate arrival or departure prediction.
17. Service alerts and TripUpdates are different products
An official alert can explain a disruption, detour or accessibility issue in text, while a TripUpdate supplies structured trip/stop predictions. They can complement one another but do not automatically carry identical scope.
What goes wrong: A long service alert for one station is not a substitute for a structured cancellation indicator on a named trip. Verification rule: Link the relevant alert only when its entity scope and active period match, and do not invent a cause absent from either product.
18. Vehicle positions and arrival predictions differ
A VehiclePosition describes a vehicle’s reported location or status, while a TripUpdate predicts schedule-related timings. A predicted arrival does not prove that a vehicle was physically observed at that predicted stop.
What goes wrong: ‘The train is at Central Station’ is unsupported if a feed merely predicts it will arrive in two minutes. Verification rule: Label geographic observations separately from predicted times; use the correct feed entity type.
19. Service dates can span midnight
GTFS Schedule uses a service date and can express times beyond 24:00 to represent after-midnight continuation of a service day. Realtime predictions and local calendar days must be matched with care.
What goes wrong: `25:10:00` interpreted as an invalid clock, or casually translated to next-day 01:10 without service-date context, can create wrong trip matches. Verification rule: Keep schedule service day and user-visible local date separate. Explain the relationship instead of silently overwriting it.
20. Uncertainty is part of prediction meaning
StopTimeEvent may include uncertainty information. Even when a feed presents a point estimate, the target language should not introduce certainty beyond what the producer supplied.
What goes wrong: ‘Will arrive exactly at 14:15’ converts a prediction into a guarantee without evidence. Verification rule: Use ‘estimated’ or ‘predicted’ where appropriate, and preserve any explicit uncertainty field.
21. Not all trip relationships have identical semantics
The GTFS Realtime reference defines relationships including scheduled, added or new, replacement, unscheduled, duplicated and cancelled, some with version-specific requirements. The precise product field and current specification determine interpretation.
What goes wrong: Treating every non-scheduled relationship as ‘new service’ can alter whether a real trip adds capacity, replaces a plan or lacks a static schedule. Verification rule: Confirm the exact enumerated relationship in the reference version and avoid inventing detailed consequences.
22. Human-readable names and machine keys must remain distinct
Static `translations.txt` allows language-specific names and descriptions; realtime trip updates mostly carry identifiers and typed values. Replacing keys with translated prose changes the data contract.
What goes wrong: A pipeline may fail after a localisation pass because `trip_id` or `stop_id` was rewritten as a passenger label. Verification rule: Localise captions and interface strings, not keys, enum values or signed numeric fields.
23. A prediction can be updated or withdrawn
Real-time feeds are snapshots. A later snapshot may revise, replace or omit a previously present update. That change should be interpreted under the feed’s state semantics rather than described as a guaranteed historical event.
What goes wrong: A screenshot of one feed state can be mistaken for a permanent announcement about service operations. Verification rule: Document snapshot timestamp and source; distinguish a historical observation about feed content from an official notice of what actually ran.
The repeatable nine-pass workflow: from structured feed to useful translation
Pass 1: Capture the precise feed snapshot
Save feed source, retrieval time, `FeedHeader.timestamp`, exact trip entity and the applicable GTFS Schedule version. Do not begin by translating a screenshot from an unknown time.
Why this matters: The first pass protects provenance. Without it, a correct sentence may be attributed to the wrong service day or a superseded prediction. In a professional review, mark which original feed field supports each final target-language sentence. A reviewer should be able to inspect that field without reconstructing your assumptions.
Pass 2: Resolve the trip against the schedule
Match `trip_id`, `start_date`, `start_time` and relevant descriptors to the static timetable. Verify route, direction and stop sequence rather than guessing from a display name.
Why this matters: A route can contain many trips. A stop can also appear twice on a loop, so a human-readable place name may not identify the correct stop visit. In a professional review, mark which original feed field supports each final target-language sentence. A reviewer should be able to inspect that field without reconstructing your assumptions.
Pass 3: Assign an evidence state to every field
Mark each value as schedule, realtime prediction, actual observation, absence of realtime data, stop-level exception or trip-level cancellation. Distinguish optional fields from explicit zero values.
Why this matters: The state map prevents a translator from making ‘no data’, ‘on time’ and ‘not running’ sound synonymous. In a professional review, mark which original feed field supports each final target-language sentence. A reviewer should be able to inspect that field without reconstructing your assumptions.
Pass 4: Build a time-and-units sheet
Copy epoch timestamps, signed delays, schedule times, local date, service day, stop sequence and whether each event is arrival or departure. Convert seconds to minutes explicitly.
Why this matters: This pass catches wrong signs, clock shifts and the especially dangerous mistake of adding a delay twice. In a professional review, mark which original feed field supports each final target-language sentence. A reviewer should be able to inspect that field without reconstructing your assumptions.
Pass 5: Apply stop-level change and propagation rules
Read every StopTimeUpdate in sequence. Compute how an announced delay is carried until superseded or stopped by the relevant relationship. Treat SKIPPED and NO_DATA according to the standard.
Why this matters: A sparse list of updates often contains more predictive meaning than its number of rows suggests. One row can determine how later stops are displayed. In a professional review, mark which original feed field supports each final target-language sentence. A reviewer should be able to inspect that field without reconstructing your assumptions.
Pass 6: Check trip-wide override status
Read `TripDescriptor.schedule_relationship` before any passenger-facing predicted time. An explicitly cancelled trip requires different wording from a skipped stop or an absent entity.
Why this matters: The higher-level status can make stop predictions inappropriate to display, even if the source contains subordinate values. In a professional review, mark which original feed field supports each final target-language sentence. A reviewer should be able to inspect that field without reconstructing your assumptions.
Pass 7: Draft targeted passenger and technical variants
Write a detailed field-by-field explanation for technical readers and a concise passenger statement that preserves the same status and time. Do not add cause, certainty or service scope.
Why this matters: The two versions may differ in length and vocabulary, but they must reconstruct the same factual meaning. In a professional review, mark which original feed field supports each final target-language sentence. A reviewer should be able to inspect that field without reconstructing your assumptions.
Pass 8: Validate language, numbers and freshness independently
Run an identifier audit, a numeric sign/unit audit, a date-time audit, an enum/status audit and a fluency review. If the producer’s data are stale or unresolved, say so explicitly.
Why this matters: A grammatical review is insufficient when ‘five minutes early’ and ‘five minutes late’ both sound natural. In a professional review, mark which original feed field supports each final target-language sentence. A reviewer should be able to inspect that field without reconstructing your assumptions.
Pass 9: Publish with traceable references and limits
Provide the data source, timing, version, relevant documentation and the boundary of the explanation. Keep live passenger instructions with the authorised operator rather than an unverified translated snapshot.
Why this matters: A good educational article demonstrates the method and directs real journeys to current information. It does not pretend that a static page is a live arrival board. In a professional review, mark which original feed field supports each final target-language sentence. A reviewer should be able to inspect that field without reconstructing your assumptions.
Worked examples: one changed word can change an actual journey
These are illustrative, synthetic data fragments. None represents live service and no traveller should make a boarding decision from them. Examples use English renderings so the distinction is visible, but the same meaning checks apply to other languages.
Example 1: Five minutes late versus 300 minutes late
Synthetic source: `stop_time_update[stop_sequence=7].arrival.delay=300`, with a matching scheduled arrival of 14:10.
Accurate interpretation: This is an arrival prediction five minutes behind schedule, corresponding to a nominal 14:15 predicted time in the example.
Misleading translation: ‘Bus delayed 300 minutes’ treats seconds as minutes and turns a small deviation into a major disruption. Transfer lesson: Reconcile the unit and schedule. The source field is a signed number of seconds, not a natural-language duration with an implicit unit.
Example 2: An early prediction
Synthetic source: `arrival.delay=-120`, with a scheduled arrival of 09:20.
Accurate interpretation: The signed delay indicates a prediction two minutes ahead of schedule, with a nominal predicted arrival at 09:18.
Misleading translation: ‘Two minutes late’ reverses the sign. ‘Always arrives early’ converts one snapshot into a general service claim. Transfer lesson: Preserve whether the time is early or late and note that a predicted time may subsequently change.
Example 3: No entity for the scheduled trip
Synthetic source: A schedule includes a trip but a feed snapshot contains no TripUpdate for that trip.
Accurate interpretation: The correct passenger-facing statement is that no realtime prediction is available in this snapshot; the scheduled time may still be shown with an appropriate label.
Misleading translation: ‘Service running on time’ is a confidence claim absent from the feed. ‘Service cancelled’ is also unsupported. Transfer lesson: Lack of realtime information means exactly that—lack of information, not proof of one operational state.
Example 4: A skipped intermediate stop
Synthetic source: The StopTimeUpdate for stop sequence 6 carries `schedule_relationship=SKIPPED`; later stops continue to have valid updates.
Accurate interpretation: The trip is not predicted to stop at that particular stop. Other stops and trip status require their own reading.
Misleading translation: ‘The whole journey is cancelled from stop 6 onwards’ generalises beyond the field’s scope. Transfer lesson: Use a stop-specific phrase and do not assume a skipped stop ends the entire trip.
Example 5: Trip-level cancellation
Synthetic source: A TripDescriptor has `schedule_relationship=CANCELED` for identified trip and service date.
Accurate interpretation: The identified trip is cancelled under the feed’s reporting semantics. The translation should identify which departure was affected.
Misleading translation: ‘Every train on this route is cancelled today’ is broader than one trip. ‘Expected to depart as normal’ ignores the trip-wide status. Transfer lesson: Confirm trip identity and status, then ensure any stop-level clocks do not contradict the cancellation.
Example 6: NO_DATA does not equal no service
Synthetic source: A StopTimeUpdate at stop sequence 10 has `schedule_relationship=NO_DATA`.
Accurate interpretation: No realtime prediction is supplied for the affected range under the propagation rules. The schedule may remain visible but is not verified as a current prediction.
Misleading translation: ‘No service at stop 10’ confuses information absence with service withdrawal. Transfer lesson: Display the schedule as schedule, not as realtime confirmation, and use a clear data-unavailable phrase.
Example 7: Propagation over a sparse list
Synthetic source: A 20-stop trip has delay +300 seconds at stop 3, +60 seconds at stop 8, and `NO_DATA` at stop 10.
Accurate interpretation: The official documentation’s example interprets stops 3–7 as +300 seconds, stops 8–9 as +60 seconds, and stops 10–20 as unknown; stops 1–2 are unknown.
Misleading translation: ‘Only stops 3, 8 and 10 are affected’ reads three listed rows and ignores their defined influence on other stops. Transfer lesson: The translation should summarise affected ranges or present them in a table, not merely translate the rows in isolation.
Example 8: Predicted time versus scheduled time
Synthetic source: A schedule says 17:30; a compatible StopTimeEvent carries an absolute predicted time corresponding to 17:34.
Accurate interpretation: A faithful sentence says the service is scheduled for 17:30 and currently predicted for 17:34, with update timing shown where appropriate.
Misleading translation: ‘The train arrived at 17:34’ asserts an actual observed event from a future prediction. Transfer lesson: Keep scheduled, predicted and actually observed language separate, especially for historical datasets where tense can be ambiguous.
Example 9: Arrival versus departure
Synthetic source: A stop's arrival prediction is 12:04 and its departure prediction is 12:06.
Accurate interpretation: The separate times describe expected arrival at and departure from the stop. A short passenger summary should identify the relevant event.
Misleading translation: ‘The train will arrive at 12:06’ mistakes the departure value for the arrival value. Transfer lesson: Do not collapse dwell time unless the source says the events coincide.
Example 10: A repeated stop on a loop
Synthetic source: A trip visits `stop_id=ST12` at stop sequences 4 and 13.
Accurate interpretation: The correct update references the intended occurrence by sequence; the same passenger name could refer to two visits on the one trip.
Misleading translation: An interface links a predicted departure from the second visit to the first one because it matched only the stop name. Transfer lesson: Preserve stop sequence and trip identity with the stop ID for disambiguation.
Example 11: A service day crossing midnight
Synthetic source: An illustrative scheduled GTFS service uses `25:10:00` for an after-midnight stop on the previous service day's journey.
Accurate interpretation: The physical local clock may display 01:10 the following calendar day, but the GTFS schedule time remains linked to the original service day.
Misleading translation: ‘Invalid 25:10 departure’ discards a valid schedule convention. ’01:10 on the original date’ may be a date error. Transfer lesson: Keep service date and calendar date distinct; check the agency time zone and the referenced trip.
Example 12: Stale feed presentation
Synthetic source: A trip's last prediction was updated at 14:01 but a user reads a translation at 14:18.
Accurate interpretation: The target sentence should not imply that 14:01 prediction is a fresh measurement at 14:18; its age or uncertainty should be stated.
Misleading translation: ‘Arrives in two minutes now’ can be misleading if the original estimate was generated long before the reader opened the page. Transfer lesson: Keep update timestamp and page retrieval timestamp in separate labels; an educational source cannot act as a live guarantee.
Example 13: Vehicle position is not a scheduled arrival
Synthetic source: A VehiclePosition shows a vehicle location while a separate TripUpdate gives a stop prediction.
Accurate interpretation: Correct wording identifies a position report and a predicted stop time as different kinds of information.
Misleading translation: ‘The vehicle has reached the stop’ is not proven by a predicted event that has not yet occurred. Transfer lesson: Maintain source entity type and avoid importing an actual-position claim from a prediction alone.
Example 14: A multilingual stop label
Synthetic source: Static GTFS contains `stop_id=ST9001`, with a different display label in each approved language.
Accurate interpretation: The translated passenger display may show a localised stop name while retaining `ST9001` for joins and audit.
Misleading translation: Replacing the `stop_id` field itself with the localised name breaks machine identity and can confuse similarly named stops. Transfer lesson: Use the separate static translations owner to define display names; this TripUpdate article preserves realtime status semantics.
Failure modes: diagnosis, source check and repair
Failure 1: Signed-delay reversal
An interface strips the minus sign and shows ‘late’ when the source predicts the vehicle is ahead of schedule. Repair: Write the sign in a review worksheet and compute the schedule difference once. Re-read the target as a passenger would. A good review is evidence-based: locate the exact feed field, restate its data type, and then check the target noun, verb, time and scope. If any of those have grown stronger than the source, rewrite the sentence before polishing its style.
Failure 2: Seconds converted as minutes
A delay of 300 appears as 300 minutes rather than five minutes. Repair: Retain raw seconds and calculate minutes explicitly; never assume the target display already converted units. A good review is evidence-based: locate the exact feed field, restate its data type, and then check the target noun, verb, time and scope. If any of those have grown stronger than the source, rewrite the sentence before polishing its style.
Failure 3: Missing update interpreted as punctuality
A scheduled trip with no corresponding TripUpdate receives a green ‘on time’ label. Repair: State absence of realtime prediction. If static time remains displayed, label it as scheduled rather than verified. A good review is evidence-based: locate the exact feed field, restate its data type, and then check the target noun, verb, time and scope. If any of those have grown stronger than the source, rewrite the sentence before polishing its style.
Failure 4: Missing update interpreted as cancellation
A trip disappears from a snapshot and the target says ‘cancelled’. Repair: Check for an actual trip-level cancellation relationship or official alert before assigning a cancellation status. A good review is evidence-based: locate the exact feed field, restate its data type, and then check the target noun, verb, time and scope. If any of those have grown stronger than the source, rewrite the sentence before polishing its style.
Failure 5: Skipped stop expanded to entire trip
A single SKIPPED stop yields a whole-route cancellation announcement. Repair: Constrain the wording to the named stop occurrence; inspect the trip and other stop updates separately. A good review is evidence-based: locate the exact feed field, restate its data type, and then check the target noun, verb, time and scope. If any of those have grown stronger than the source, rewrite the sentence before polishing its style.
Failure 6: NO_DATA confused with stop closure
An unknown arrival becomes ‘service withdrawn’. Repair: Explain that realtime predictions are unavailable for the stop context and retain source uncertainty. A good review is evidence-based: locate the exact feed field, restate its data type, and then check the target noun, verb, time and scope. If any of those have grown stronger than the source, rewrite the sentence before polishing its style.
Failure 7: Propagation ignored
A sparse TripUpdate list is translated as if unlisted stops cannot inherit a delay. Repair: Apply the documented propagation rules to every relevant scheduled stop in order. A good review is evidence-based: locate the exact feed field, restate its data type, and then check the target noun, verb, time and scope. If any of those have grown stronger than the source, rewrite the sentence before polishing its style.
Failure 8: Overriding trip status ignored
A cancelled trip still appears with predicted arrival values. Repair: Read the trip relationship before stop-level clocks; suppress or qualify any subordinate times as the standard requires. A good review is evidence-based: locate the exact feed field, restate its data type, and then check the target noun, verb, time and scope. If any of those have grown stronger than the source, rewrite the sentence before polishing its style.
Failure 9: Arrival and departure mixed
The target says ‘arrives’ but displays the departure prediction. Repair: Check field path `arrival` versus `departure` before choosing verbs. A good review is evidence-based: locate the exact feed field, restate its data type, and then check the target noun, verb, time and scope. If any of those have grown stronger than the source, rewrite the sentence before polishing its style.
Failure 10: Epoch interpreted as local HH:MM
A UNIX timestamp becomes a wrong calendar or day without a time-zone conversion. Repair: Convert with a verified zone-aware function in the source system and preserve the underlying epoch for audit. A good review is evidence-based: locate the exact feed field, restate its data type, and then check the target noun, verb, time and scope. If any of those have grown stronger than the source, rewrite the sentence before polishing its style.
Failure 11: Overnight service date lost
A service-day 25:10 stop gets called invalid or is attached to the wrong travel day. Repair: Resolve service date, agency time zone and actual local calendar date as separate fields. A good review is evidence-based: locate the exact feed field, restate its data type, and then check the target noun, verb, time and scope. If any of those have grown stronger than the source, rewrite the sentence before polishing its style.
Failure 12: Stop name used as stable key
A translated name replaces the actual `stop_id` in a data contract. Repair: Keep machine identifiers unchanged; attach localised names only as presentation fields. A good review is evidence-based: locate the exact feed field, restate its data type, and then check the target noun, verb, time and scope. If any of those have grown stronger than the source, rewrite the sentence before polishing its style.
Failure 13: Same-stop loop ambiguity
A repeated stop in one trip is matched to the wrong occurrence. Repair: Use stop_sequence with stop_id and trip instance when the stop repeats. A good review is evidence-based: locate the exact feed field, restate its data type, and then check the target noun, verb, time and scope. If any of those have grown stronger than the source, rewrite the sentence before polishing its style.
Failure 14: Stale data presented as live
A snapshot timestamp is dropped, making an old prediction sound like an immediate live update. Repair: Retain feed timestamp and explain data freshness; refer passengers to current authoritative operator information. A good review is evidence-based: locate the exact feed field, restate its data type, and then check the target noun, verb, time and scope. If any of those have grown stronger than the source, rewrite the sentence before polishing its style.
Failure 15: Alert narrative and TripUpdate merged without scope
A broad disruption notice is applied to every specific trip without validating affected entities or periods. Repair: Keep alert active period and entity selectors distinct from TripUpdate status and prediction fields. A good review is evidence-based: locate the exact feed field, restate its data type, and then check the target noun, verb, time and scope. If any of those have grown stronger than the source, rewrite the sentence before polishing its style.
Failure 16: Vehicle position mistaken for actual arrival
A projected time or nearby GPS point is described as an observed boarding event. Repair: Translate the actual entity type and qualify prediction versus reported location. A good review is evidence-based: locate the exact feed field, restate its data type, and then check the target noun, verb, time and scope. If any of those have grown stronger than the source, rewrite the sentence before polishing its style.
Failure 17: Cause invented from status
A cancellation is explained as a mechanical failure, strike or weather closure without supporting alert text. Repair: State only that a trip is marked cancelled; add the reason only if an appropriately scoped reliable source provides it. A good review is evidence-based: locate the exact feed field, restate its data type, and then check the target noun, verb, time and scope. If any of those have grown stronger than the source, rewrite the sentence before polishing its style.
Practice and transfer: make the method work on unfamiliar data
Practice 1: Build the trip identity card
Create an imaginary GTFS scheduled trip with `trip_id`, route, start_date, start_time and ordered stops. Keep IDs intact while preparing two localised display-language versions.
Self-check: A partner should be able to match both language versions to the same trip without relying on translated route titles alone. In every exercise, include the original token alongside the proposed translation so that the correction remains testable rather than a stylistic opinion.
Practice 2: Check units and signs
Translate three synthetic delays: `300`, `-120` and `0` seconds. Write the duration and whether each is ahead of, behind or matching the scheduled time.
Self-check: A correct answer is five minutes behind, two minutes ahead and zero schedule deviation. No answer should introduce a guaranteed future arrival. In every exercise, include the original token alongside the proposed translation so that the correction remains testable rather than a stylistic opinion.
Practice 3: Distinguish absence and punctuality
Show a scheduled trip with no realtime entity and ask students to draft a 15-word status statement.
Self-check: The statement must not say ‘on time’ or ‘cancelled’. It can say that only scheduled information is available. In every exercise, include the original token alongside the proposed translation so that the correction remains testable rather than a stylistic opinion.
Practice 4: Distinguish SKIPPED from CANCELED
Write one sample where only stop sequence 4 is skipped and another where the trip itself has CANCELED status.
Self-check: The first translation must name the omitted stop; the second must name the particular cancelled trip, not an entire route by default. In every exercise, include the original token alongside the proposed translation so that the correction remains testable rather than a stylistic opinion.
Practice 5: Apply propagation on twenty stops
Use the official 20-stop example: +300 s at stop 3, +60 s at stop 8, NO_DATA at stop 10. Create a short paragraph and table identifying the affected ranges.
Self-check: Check that the translated explanation covers stops 3–7, 8–9 and 10–20 correctly, with unknown status for stops 1–2. In every exercise, include the original token alongside the proposed translation so that the correction remains testable rather than a stylistic opinion.
Practice 6: Convert a service day correctly
Write a synthetic service starting at 23:30, with a stop at GTFS time 25:10. Explain the service-day interpretation and local calendar date.
Self-check: The example should show that time past 24 hours can be valid in static GTFS while remaining connected to the prior service day. In every exercise, include the original token alongside the proposed translation so that the correction remains testable rather than a stylistic opinion.
Practice 7: Audit prediction age
Compare an update generated at 14:01 with a report read at 14:18 and write a careful status sentence.
Self-check: The target must identify the last update time, not claim that the prediction is a fresh observation at the reading time. In every exercise, include the original token alongside the proposed translation so that the correction remains testable rather than a stylistic opinion.
Practice 8: Arrival-departure distinction
Give one stop with arrival 12:04 and departure 12:06. Create separate target-language labels for the two times.
Self-check: The translation should preserve which event occurs at which instant, even when a public display later abbreviates one label. In every exercise, include the original token alongside the proposed translation so that the correction remains testable rather than a stylistic opinion.
Practice 9: Loop-stop disambiguation
Create a trip that visits the same stop ID at sequences 3 and 12. Translate a StopTimeUpdate referring to the second visit.
Self-check: A correct technical annotation retains the sequence. A passenger-facing line should not accidentally refer to the first visit. In every exercise, include the original token alongside the proposed translation so that the correction remains testable rather than a stylistic opinion.
Practice 10: Reconstruct a structured record from prose
Have a partner read only your translated summary, then ask them to identify the scheduled trip, realtime status, stop status, time basis, delay sign and freshness.
Self-check: If they reconstruct a different status or infer a guarantee you did not mean, revise the sentence. The test is semantic recoverability, not literary smoothness. In every exercise, include the original token alongside the proposed translation so that the correction remains testable rather than a stylistic opinion.
Practice 11: Transfer the evidence-state rule
Apply the same discipline to an air-quality sensor measurement, aviation TAF forecast or clinical study result. Identify measurement versus prediction, present versus missing data, and observation versus official status.
Self-check: The transferable habit is to protect evidence type, source identity, time, unit and uncertainty before crafting an accessible explanation. In every exercise, include the original token alongside the proposed translation so that the correction remains testable rather than a stylistic opinion.
Frequently asked questions about GTFS Realtime translation
What is a GTFS Realtime TripUpdate?
It is a structured feed message describing schedule deviations and predictions for a specific trip, including arrival and departure estimates and certain stop-level or trip-level relationships. It complements rather than replaces the base GTFS Schedule record.
Does no TripUpdate mean the bus is on time?
No. The official reference explains that absence of a realtime TripUpdate means no prediction information is available for that trip; it does not establish punctuality. Show scheduled times as scheduled and label the realtime status as unavailable.
Is 300 a delay of 300 minutes?
Not in the relevant GTFS Realtime delay fields. Delay is expressed in seconds; positive 300 means five minutes behind schedule. Always identify the field before converting any numeric value for passengers.
Does a negative delay mean the trip is cancelled?
No. Negative delay indicates running or predicted ahead of schedule in the defined delay field. For example, -120 seconds means two minutes ahead, not that the trip has stopped running.
How is SKIPPED different from CANCELED?
SKIPPED belongs to a stop-level relationship and indicates a particular stop is not served. CANCELED at trip level identifies an entire trip as cancelled. Neither should automatically be expanded to all trips on a route.
What does NO_DATA mean in a stop update?
It identifies a lack of realtime stop prediction information in the specified context. The standard also describes how such a stop update affects carried delay propagation. It is not proof that a bus or train will not operate.
Why can one delay affect later stops not listed explicitly?
TripUpdates may be sparse. The official Trip Updates guide explains delay propagation to following stops until superseded or stopped under its rules. A reader must interpret the complete ordered trip rather than treat every listed stop as isolated.
What happens if the same stop appears twice in a trip?
Keep the stop identifier plus the ordered stop_sequence to identify which visit the update means. A translated stop name by itself may be insufficient and can misdirect a prediction to the wrong portion of a loop service.
Do realtime timestamps use the passenger’s local time zone?
GTFS Realtime timestamps use POSIX epoch seconds. The consumer can convert them for display using the correct time zone and service date, but should keep the raw value available for audit. Static GTFS also has service-day conventions that can cross midnight.
Are scheduled and predicted arrival times interchangeable?
No. A scheduled time comes from the timetable and a predicted time from the realtime update. An eventual observed arrival is a third evidence state. The target language should preserve those differences.
Why do arrival and departure each need a label?
A vehicle may arrive at a stop before it departs. A target-language summary that labels departure as arrival can give passengers the wrong moment to board, even when the displayed clock is copied correctly.
Can I translate trip_id and stop_id into another language?
Not as machine fields. Keep IDs, enum values and protocol keys unchanged. Translate display names, explanations and accessibility text using appropriate static GTFS translation support and authoritative naming choices.
Can a service alert explain a cancellation?
Yes, when the alert is relevant to the same trip, route, stop, and active period, it may provide a reason or passenger advice. But an alert is a separate feed entity and should not be assumed to apply to every TripUpdate.
Does a predicted time guarantee a vehicle will arrive?
No. A prediction is an estimate derived from currently available data and may change. A translation must retain prediction language, freshness and uncertainty rather than promising punctual service.
What is the best learning order?
Start by matching IDs against the static schedule, then learn signed seconds, event time, stop order, propagation rules, NO_DATA, SKIPPED, CANCELED and feed freshness. Practise on synthetic examples before interpreting real records.
How does this differ from translating bus timetable notices?
Timetable and general service-alert guides explain passenger schedules and announcements. This article owns the machine-readable GTFS Realtime TripUpdate semantics that underpin many arrival displays, especially missing data, per-stop prediction and trip cancellation.
Can a general AI translator handle this without human review?
It may help translate surrounding prose but can confuse missingness, status scopes, signed delays and time zones. Preserve raw fields and require a semantic and numerical review before a passenger-facing interpretation is trusted.
Contextual internal links: where this subject fits
For static stop and route names, the distinct owner is GTFS translations.txt and stop/route name QA; for route diagrams and wayfinding, use translating public transit maps. Those articles explain separate jobs. The canonical question answered here is how to preserve structured TripUpdates, signed delays, missing predictions and cancellation scopes across languages.
For the wider evidence-state discipline, compare METAR and TAF aviation weather reports, where observations and forecasts have different meanings, and air-quality PM2.5 sensor and index records, where a measurement is different from a communication index. For overall method see Master Art of Translation, the Top Ways series index, the Vocabulary Learning Hub and How English Works.
For technical cross-checks, begin with GTFS Realtime Trip Updates, the field and relationship reference, feed best practices and the GTFS Schedule reference. Read version-specific details in the original source specification and compare the actual agency feed before drawing operational conclusions.
Final translation test: could a careful second reader reconstruct the exact trip, source schedule, prediction status, signed delay, arrival-versus-departure label, stop- versus trip-level relationship, service date and last-update time from the translation? If not, shorten the claim or add the missing evidence. Real-time transport language is useful when it is both understandable and faithful to the journey data.