Glossary
Darwin
Darwin is Network Rail's real-time live departures feed on the UK National Rail Data Portal, serving per-train forecast calls at stations for the current day plus the forward schedule. The portal's developer guidelines require keeping end-user forecasts consistent with it.
What is Darwin?
Darwin is the live-departures system behind UK rail prediction displays. On the cataloged National Rail Data Portal (UK) record it appears first in the short description - "Darwin live departures, DTD timetable extracts, Knowledgebase reference data" - marking it as the real-time member of a three-part offering. Its coverage statement is precise: "Darwin forecasts cover the current day plus forward schedule", so the feed answers both today's platform calls and upcoming timetabled trains. Access sits behind integration key registration and carries licensing under the NRE Open Data licence, while the message layer is associated in this slice with STOMP messaging and SIRI-format exchange - the pieces a consumer assembles into a working departures board.
Why does Darwin matter when choosing a dataset?
Darwin is authoritative, and the portal says so contractually: the Developer Guidelines require "keeping end-user forecasts consistent with Darwin". An app that blends Darwin with a cached or self-computed schedule and shows something different has drifted outside its terms, not merely made a data-quality mistake. The practical consequence is architectural - your presentation layer must be a view of the feed rather than a reinterpretation of it. Scope discipline matters equally: because coverage is the current day plus the forward schedule, Darwin is not an archive. Longitudinal punctuality studies need a store built up over time or a different historical product, and teams that discover this late find they cannot backfill the months they skipped.
How do you evaluate Darwin in a data source?
- Confirm feed scope before designing storage Coverage is stated as "Darwin forecasts cover the current day plus forward schedule" - plan your own archive if you need history.
- Quote the consistency rule in your integration spec Developer Guidelines require "keeping end-user forecasts consistent with Darwin", which constrains how much local adjustment a consumer may apply.
- Identify the access stack up front Registration plus the associated STOMP and SIRI components determine how quickly a prototype becomes a production feed.
- Pair it with the schedule and reference products "DTD timetable extracts, Knowledgebase reference data" complete the picture Darwin's live calls annotate.
Related terms
Neighboring entries cover the registration, licensing and message formats around this feed:
api-key-registration is the sign-up gate before pulling live departures. nre-open-data-licence sets the reuse conditions for portal data including Darwin. siri is the exchange format these schedule and status messages travel in.
Browse curated sources in rail-transportation data, where the National Rail Data Portal record lives.
Frequently asked questions
What data does the Darwin feed cover?
Per the National Rail Data Portal record, Darwin forecasts cover the current day plus the forward schedule, delivering per-train forecast calls at stations. It sits alongside DTD timetable extracts and Knowledgebase reference data.
Can I modify forecasts shown to my users?
No. The portal's Developer Guidelines require keeping end-user forecasts consistent with Darwin, so consumers display the feed's predictions rather than recomputing or overriding them.
Datasets containing this field
Datasets containing Darwin
6 datasets carry darwin in the catalog. Open one, count the fields, judge for yourself.
DB Open Data and DB Developer Portal
station_directory · station_profile · service_centre_directory …+8 more
EU Open Data Portal - Railway Datasets
HuggingFace Railway Datasets
Every listing shows the field dictionary, sample rows, and coverage before you commit. API, files, or your warehouse. Daily, weekly, or hourly.
Get sample rows