Using Open Railway Data: Data Sources for Your Own Projects

Updated: August 2026 – At some point the app just isn’t enough: you want your own departure board for the hallway monitor, an analysis of which classes pass through your local station, or a map with your favourite lines. This guide shows which open railway data exists, how current and how accessible it is – and how to turn a download into something of your own in a short time.

Open railway data: what data even exists

Open railway data falls into three categories: scheduled data (the planned timetable), real-time data (the deviation from the plan) and infrastructure data (lines, operating points, stations). For timetables, GTFS has become the standard exchange format, for real time it’s GTFS-Realtime and SIRI, and for European standardisation it’s NeTEx.

The most important starting point is a national access point, through which mobility data in Germany is made centrally discoverable; on top of that, many transport associations and operators run their own data pages. The interface standards behind them come predominantly, in German-speaking countries, from the Association of German Transport Undertakings. Which datasets currently sit there and under which licence is decided by the providers themselves – and occasionally changed. Just how differently the transport associations handle this is shown by the real-time check of the transport associations.

The data sources at a glance

The following table sorts the common source types by what actually matters for a project: format, currency, access barrier and licence situation. Concrete licences always sit with the dataset itself – the column only describes what’s typical.

Source type	Format	Typical currency	Access barrier	Licence situation
Nationwide scheduled dataset	GTFS, sometimes NeTEx	Updated daily to weekly	Download, usually no registration	open licence, usually with attribution
Transport-association scheduled data	GTFS	as above, sometimes maintained in finer detail	Association’s data page	varies by association
Real-time feeds	GTFS-Realtime, SIRI	Seconds to a few minutes	often registration required	often with terms of use
Operator interfaces	JSON, XML	close to the operations control system	Registration, sometimes quotas	provider-specific
Infrastructure from OpenStreetMap	Raw OSM data, vector tiles	ongoing, community-maintained	free, but needs processing	open data licence with share-alike
Station data	CSV, JSON	rare, planning-driven	mostly open	open licence, check the terms
Vehicle and sighting knowledge	Lists, forums, apps	ongoing, but incomplete	freely readable, barely machine-readable	copyright-protected, clarify use

The last row is the decisive gap: everything to do with specific vehicles is completely missing from the official data streams. That’s exactly why communities exist – see the overview of live sightings in trainspotting.

Understanding GTFS: the five files that matter

A GTFS archive usually contains a dozen files, but to start with you only need five. They’re linked by IDs, like tables in a database.

• stops.txt – all stops with ID, name and coordinates. Your entry point when you’re thinking from a location.
• routes.txt – the routes with short name, long name and mode of transport. This is where you separate rail from bus and tram.
• trips.txt – the individual trips of a route, each with a direction and a reference to a calendar entry.
• stop_times.txt – by far the largest file: every arrival and departure of every trip at every stop. This is where the actual information sits.
• calendar.txt and calendar_dates.txt – which days of the week a trip runs on and which exceptions apply. Without these files, you’ll accidentally build a board that shows school buses on Sundays too.

From download to your own departure board

The fastest route to a visible result runs through six steps. Each one is small on its own – the trick is going through them in this order and not starting with real time.

Connecting real-time data: what matters

Real-time feeds aren’t a standalone timetable, they’re a correction layer. GTFS-Realtime has three message types, and the differences are practically relevant:

• TripUpdate – delays, changed stops and cancelled trips. This is the type you need for a departure board.
• VehiclePosition – the current vehicle position. Only usable if the provider releases it; noticeably rarer for rail services than for buses.
• Alert – disruption and diversion messages as free text, linked to affected routes or stations.

Two pitfalls show up in almost every project. First: IDs have to match up. A real-time feed references trips from a specific scheduled dataset. If you mix a feed and a timetable from different sources, you’ll find no matches. Second: respect the query frequency. A feed that’s regenerated every 30 seconds doesn’t need to be queried more often – more frequent access doesn’t give you better data, it just costs quota.

How much data quality and presentation can differ becomes obvious the moment you compare it with finished tools. The comparison of live train radar tools shows how differently others process the same raw data, and the guide to tracking DB train numbers explains how to cleanly identify a single service.

Infrastructure data for photo locations and maps

For spotters, it’s often not the timetable that’s interesting, but the line itself. Here, community projects based on OpenStreetMap provide the most practical foundation: track layouts, electrification, line numbers, operating points and sometimes signals are mapped there and can be added as a map layer.

Three notes on that:

• Completeness isn’t guaranteed. Community maps are good, but not official. That’s enough for location planning, not for operational statements.
• Respect share-alike. Open map data is often licensed in a way that requires derived databases to be opened up again. For a map on your own website, an attribution note is usually enough; anyone processing the data further should look more closely.
• Check accessibility. A map shows tracks, but not rights of access. Track areas and operational railway land remain strictly off-limits – every location must be reachable from publicly accessible ground.

If you want to publish your own data along with a map, the technical implementation is covered in the guide to building your own spotter website. And when it’s about historical images rather than live data, it’s worth looking at the railway archive with historical railway photos.

Common mistakes in your own data projects

• Starting with real time. Without a working scheduled-data base, the real-time feed has nothing to reference. Timetable first, correction second.
• Ignoring operating days. A board without a calendar check shows trips that don’t run that day at all – the most common beginner mistake of them all.
• Confusing time zones and operating days. GTFS allows times past 24:00, such as 25:10 for a trip after midnight. Parse that naively and you lose the night services.
• Leaving out licence notices. Attribution is the rule for open data, not the exception. A sentence in the imprint costs nothing.
• Inferring vehicles from trip data. A train number tells you something about the category and route, but nothing about the class deployed. How much a number actually reveals is explained in the article on decoding train numbers.
• Overlooking tunnel and special services. Underground lines follow their own positioning principles, as the article on tracking underground trains in tunnels shows – vehicle positions are especially often missing there.

Conclusion

Open railway data is more accessible than most people assume: a GTFS archive and a spreadsheet program are enough for the first visible result, and the step up to real time is manageable after that. The real effort isn’t in the download, it’s in the care taken – with operating days, IDs and licences. And one limit remains no matter how skilled you are technically: no feed will tell you which vehicle is actually running.