What Is a Useful Freshness Indicator for Transit Data?
From the earlier reference collection. Read the current software blog.
Transit data freshness concerns when a feed was published or received; scheduled trip times describe planned service and answer a different question.
Separate feed time from trip time
A transit schedule contains times that describe when service is planned to run. Those times do not tell a reader when the schedule file was published or when a dashboard last retrieved it. A freshness indicator should show the feed’s publication time when available and the dashboard’s successful retrieval time, since those describe different steps.
For example, a trip listed at 8:20 a.m. is a planned departure, not evidence that the feed updated at 8:20. Labeling it “updated at 8:20” would conflate schedule content with data freshness and could lead a rider or analyst to infer a live status that the schedule does not provide.
Show the relevant timestamps
Put a clear “Schedule feed published” or “Data retrieved” time near the schedule view. Include the date and time zone where ambiguity is possible. If the source has no publication timestamp, say when the dashboard last fetched it and avoid implying that this proves when the source itself changed.
A schedule may remain valid for a future service period even if the file has not changed today. Freshness is not the same as usefulness: the indicator should help readers understand file age while the page separately identifies the service dates the schedule covers.
Define delayed status for the feed
Set a freshness expectation appropriate to the source. A static schedule feed may be expected to change only when an agency publishes a revision, so a short interval threshold intended for rapidly changing vehicle positions would be misleading. The dashboard can report the feed’s version or retrieval date and flag an unexpected retrieval failure without calling an unchanged schedule stale.
If the page also uses a real-time source, present its status separately. A current real-time update does not make the underlying schedule file newly published, and a current schedule file does not mean vehicle positions are live.
Explain what the indicator supports
A useful status might read: “Schedule file retrieved Oct 28 at 9:10 a.m. Pacific; service dates shown: Oct 1–Dec 14.” This distinguishes the retrieval event from the calendar periods encoded in the schedule. The exact fields available depend on the feed and its metadata, so interfaces should not promise a publication timestamp where none is supplied.
Transit data is easier to interpret when planned service time and data-processing time have separate labels. Keep both visible where they matter, and readers can tell what is scheduled from how recently the schedule information was obtained.