Homepage > PID Opendata

PID Opendata

Open data is processed primarily for data analysts and transport application developers. Regularly updated timetables, online information on the locations of connections, as well as statistical data on Prague Integrated Transport are available.

In addition to being placed here, the datasets are also transferred to the Institute of Planning and Development, which, after further processing, also places them on the Prague opendata portal. The datasets are also processed by the Golemio data platform.

License

The data that can be downloaded directly from the website, like the entire website content, is licensed under CC-BY, meaning it can be distributed further, but the author and any changes made must be mentioned. Data that can be downloaded from other sources linked here are governed by the license of the given source.

The data located here is provided as a “preview” without warranty. It may be deleted, moved, or the format may be modified without prior warning. The data may also be missing some information that is subject to stricter licenses.

Contact

If you are interested in using some of the datasets systematically, or would like any other support, please write to us at opendata@pid.cz.

Data sets

Data set Update frequency Format / External link Details
PID Timetables in GTFS format
Timetables of all PID lines (Prague + region) for 14 days in advance.		 daily [GTFS] documentation
Current vehicle positions, connection delays
Information on the positions and delays of all vehicles on lines within PID provided in real time + departures of services from stops
 online (API) GTFS Realtime or Golemio API JSON
PID stop list
All stops, nodes, names, zones and stop locations		 daily [XML] [JSON] [XSD], dokumentace
PID sales points
Places where you can purchase tickets, subscription coupons, or apply for a PID card (machines, contact points, stations)		 approx. monthly [XML] [JSON] [XSD], documentation
Dials: [XML] [JSON] [XSD]
GeoData
Routes, lines, stops, metro entrances and fare zones and in various formats (GeoJSON, Shapefile, …)		 daily [opendata.praha.eu]
News, service disruptions and planned restrictions real-time [RSS feeds]
Annual PID statistics (only in Czech) annually [opendata.praha.eu]
Additional datasets can be found on the portal opendata.praha.eu

Documentation

Timetables in GTFS format

The file contains timetables for all PID lines (metro, trams, buses, funicular, ferries, trains), route information, guaranteed connections between connections, data on the structure of metro stations and information on the fare for calculating the price of a ticket in Prague. However, the train timetables are only experimental for now, they may contain inaccuracies in case of closures! The file is generated every day between approximately 4:00 and 4:30.

Data meets specification GTFS Static. The specifics of the PID timetable file and files and columns beyond the specification are listed below. These specifics serve only to improve understanding and human readability of the data, or provide additional information for the correct use of this data, and do not affect its validity.

agency.txt

  • Due to the uniformity of the tariff, only the common carrier “PID” is listed. The distribution of lines between the contractual carriers includes a set route_sub_agencies.txt.

stops.txt

  • The file only contains stops that are currently in use, i.e. there are connections stopping at the stop on at least one day of the feed’s validity. If the stop is (even temporarily) out of service, it will not be included.
  • Metro stations have two stops (one for each direction) combined into one station. The stop_id of this station is in the form Uhub_numberSindex. At metro transfer stations there are four stops, divided into two stations, see below.
  • Train stops and stations are currently represented by a single Stop record. In the future, it is planned to create a Station record for stations with at least two platforms and distinguish between individual platforms. The file also contains some points that are not stations and are used as transit points (stop_id starts with the letter ‘T’).
  • In addition to stops and stations, the file also includes intermediate nodes and boarding areas, which are not stops (see GTFS specifications)

U1072S1,”Můstek – A”,50.08353,14.42456,”P”,,1,,1
U1072S2,”Můstek – B”,50.08341,14.42339,”P”,,1,,1
U1072Z101P,”Můstek – A”,50.08312,14.42496,”P”,,0,U1072S1,1,M1
U1072Z102P,”Můstek – A”,50.08394,14.42415,”P”,,0,U1072S1,1,M2
U1072Z121P,”Můstek – B”,50.08321,14.42279,”P”,,0,U1072S2,1,M3
U1072Z122P,”Můstek – B”,50.08361,14.42398,”P”,,0,U1072S2,1,M4

  • zone_id describes the tariff zone of the stop (P, 0, B, 1, 2, … but also e.g. “B,1”). It can be empty for lines with a special tariff (e.g. AE), or contain a dash for stops/stations outside the PID system. Since different lines can be classified into different tariff zones at one stop, the stop can be split into multiple “virtual” entries, all of which share the same position on the map. This is necessary, for example, for calculating the price. Physically, only one stop sign is then in place. Below is an example of an exit stop at Černý Most.

U897Z1P,”Černý Most”,50.10912,14.57713,“P”,…,V1    <– for urban lines
U897Z1,”Černý Most”,50.10912,14.57713,“0”,…,V1      <– for suburban lines in zone 0
U897Z21,”Černý Most”,50.10912,14.57713,“B,1”,…,V1 <– for suburban lines in zones B,1

  • <platform_code is the platform code used to identify a platform within a group of stops
  • asw_node_id and asw_stop_id (the node number and the stop number within the node) together form the stop identifier used in some PID applications and systems
  • One stop can have multiple records if any of its properties (for example, accessibility or location) changes during the feed.

stop_times.txt

  • For train lines, the route also includes points that the trains pass through (to specify the route) – distinguished by pickup_type and drop_off_type according to the specification.
  • shape_dist_traveled describing the distance from the start on the route always has its counterpart in shapes.txt (there is always an entry in shapes.txt with identical coordinates) to make it easy to divide the route into intermediate stop segments.
  • trip_operation_type distinguishes a regular route (value = 1) from výjezdů, zátahů and moving with passengers outside the regular route of the line (value &gt 1).
    • 1 = regular service on the route
    • 7 = výjezd arrival to the regular route
    • 8 = zátah departure from the regular route
    • 9 = transfer on a line outside the regular route
    • 10 = transfer to another line
    • Explanation: The value is used only for trams, because in other tractions, route výjezdy a zátahy are not public and without passengers. Regular connections and connections that leave the depot on their route or zátah the depot on their route are managed as regular (operation type = 1). Connections that leave the depot outside their route have operation type = 7 up to the first stop on the route (not inclusive) and then operation type = 1. Connections that leave the route have operation type = 1 up to the last stop on the regular route (not inclusive) and then operation type = 8.
  • bikes_allowed determines the possibilities of transporting bicycles on the service at a given stop
    • 0 = no information about bicycle transportation
    • 1 = bicycle transportation is possible
    • 2 = bicycle transportation is not possible
    • 3 = bicycle transportation is possible, but it is not possible to board or alight with the bicycle at this stop
    • 4 = bicycle transportation is possible or to board with the bicycle, but it is not possible to alight with the bicycle
    • 5 = bicycle transportation is possible or to alight with the bicycle, but it is not possible to board with the bicycle

routes.txt

  • route_short_name corresponds to the public route designation (e.g. “A”, “22”, “S9”, “P7”).
  • route_long_name corresponds to the licensed route of the line (it does not necessarily have to agree with the real route, for example in the case of a closure!)
  • is_night informs whether it is a night line
  • is_regionalal informs whether it is a suburban or regional transport line, i.e. it also or exclusively serves areas outside Prague
  • is_substitute_transport informs whether it is a substitute transport line

trips.txt

  • block_id is constructed as the trip_id of the first connection in a sequence of connections that connect to each other. See below an example of a connection of line 174, which changes number in Luka stop and continues as a connection of line 301 to Chýnice. Only connections where the vehicle continues and passengers do not have to change are connected via block_id. Guaranteed connections with a transfer are captured in transfers.txt.

L174,1111100-1,174_17_180509,”Luka”,0,174_17_180509,L174V6,1,2,1,0
L301,1111100-1,301_2_180509,”Ořech”,0,174_17_180509,L301V1,1,2,1,0

  • A special case of using block_id are tram výjezd a zátah connections from/to a depot that transport passengers. If the depot is not directly on the line route, the connection is split at the last/first stop on the regular route of the line into two separate trips connected via block_id. The example below shows a zátah of line 5 from Sídliště Barrandov to Vozovna Motol (the last stop on the route is Anděl). Výjezd a zátah connections are currently managed as one trip. The trip_operation_type column in stop_times.txt is used to distinguish between the regular and výjezd/zátah parts of the route.
  • trip_operation_type is now moved to stop_times.txt, as it can take on different values ​​during the connection. This column has been removed from trips.txt.
  • exceptional indicates that this is an irregular connection or line. Currently, exceptional = 1 for tram výjezd a zátah connections and for tourist train lines, otherwise 0.
  • sub_agency_id indicates the carrier ID from the route_sub_agencies.txt file (sub_agency_id). For lines operated by multiple carriers, it is used to distinguish which carrier provides a specific connection.

calendar.txt

  • service_id contains a string of seven zeros and ones that indicate when the service runs for each day of the week for better human readability
  • The validity is always at least 14 days from the date of generation, trains are generated for the entire timetable.

transfers.txt

  • The file contains guaranteed transfers between connections. A guaranteed transfer is one where the connecting connection is obliged to wait for the arrival of the connecting connection. Typically, this is limited by a limit on how long the connecting connection must arrive to avoid waiting too long. This limit is given in the max_waiting_time column.

route_sub_agencies.txt

  • The file contains information about which carrier (company) operates which line.
  • Columns:
    • route_id is the route ID from routes.txt
    • route_licence_number is the route number in the national information system (CIS) of the Czech Republic [optional column]
    • sub_agency_id is the internal ID of the carrier
    • sub_agency_name is the name of the carrier operating the given route
  • If multiple carriers are involved in operating a single line, the file contains multiple records with the same route_id

route_stops.txt

  • The file contains a typical route for a given line and direction
  • Highly experimental for now

20. 3. 2023
  • Added column max_waiting_time to transfers.txt
14. 10. 2022
  • Added column sub_agency_id to trips.txt
31. 8. 2021
  • Added columns asw_node_id and asw_stop_id to stops.txt
25. 6. 2021
  • Added column bikes_allowed to stop_times.txt
  • Removed column trip_operation_type in trips.txt
13. 5. 2021
  • Moved column trip_operation_type from trips.txt to stop_times.txt
20. 4. 2021
  • Added column route_stops.txt (does not contain relevant data yet)
4. 3. 2021
  • Adding line type information to routes.txt: is_regional and is_substitute_transport
15. 12. 2019
  • Train loading adjustment
    • The entire schedule is now in GTFS (until next December).
    • Train stations and stops are currently represented by one stop in stops.txt.
    • In stops.txt, there are also auxiliary points that are not stops and stations, in stop_times.txt there are also records for trains when the train does not stop at the station (for route and time correction – distinguished by pickup_type and drop_off_type).
    • trip_short_name for train connections corresponds to the public train name (e.g. “R 670”).
    • headsign for train connections corresponds to the actual station the train is going to (even outside the PID).
29. 10. 2019
  • Added files pathways.txt and levels.txt, which describe the structure of selected metro stations (stations are gradually being added)
  • stops.txt may also contain entries of the type Intermediate node and Boarding area.
24. 6. 2019
  • Added level_id column to stops.txt (not used yet, in the future for integration of Pathways & Levels extension)
6. 1. 2019
  • Added metro entrances to stops.txt
29. 11. 2018
  • Added file route_sub_agencies.txt, which contains the original information about carriers in the system
20. 11. 2018
  • Merged carriers into a common “PID” record. Thanks to this, lines operated by multiple carriers could also be merged into one record. At the same time, the original_route_id column, which contained the license number of the line, was deleted (now it would be ambiguous)
  • Added is_night column to routes.txt, according to which it is possible to recognize a night line
  • Added trip_operation_type column to trips.txt (see documentation above)
  • Night lines related to the previous operating day have departure times up to 30:00, they do not have their own calendar as before.
11. 5. 2018
    • Adjusted the trip_id format to be stable between feeds (the same connection should now have the same ID the next day). trip_id now consists of three parts – line number, connection number (assigned sequentially) and date of first occurrence

v

  • Adjusted the stop_id format – if a stop changes during the validity of the feed (e.g. renames or changes zone), a record is added whose ID also contains the date of the start of validity of this new record
  • block_id is not filled in if there is no transfer from/to the connection and the connection would be the only one in the block
  • Adjusted the line colors according to the PID graphic manual

 

PID stop list

Stop list files provide more detailed information about stop columns that do not fit in the GTFS feed, which also does not allow for data structuring. It is available in XML and JSON formats, which are content-compliant. There is an XML schema for the XML format that describes the format. The individual entities are briefly described below.

Groupes <group>
A group defines all stops at the same node that have the same name. The unique identifier of the group is the triplet (name, districtCode, isTrain), or the pair (idosName, isTrain), or the name uniqueName.

  • name is the common name of the stops in the group. Please note that there may be multiple groups with the same name, see the example below.
  • districtCode is the code of the district in which the stop is located.
  • isTrain is true if it is a train station. The default value is false.
  • idosName is the name used in applications (IDOS etc.)
  • fullName is the full name of the stops with abbreviations written out (“rozc.” -> “rozcestí” etc.)
  • uniqueName is the name of the stops, which is unique within the entire file. It is based on idosName, where in case of a collision between a train and a non-train station, the text “(vlak)” is added to the train name.
  • node is the node number to which the stops belong. Please note that this number is not a unique identifier for the stop name, as one node can contain multiple stops with different names. An example is node 237, which groups the stops Karlovo náměstí, Palackého náměstí, Moráň and Novoměstská radnice. All these groups of stops have the same node number.
  • avgLat, avgLon, jtskX, jtskY is the GPS/JTSK position aggregated from stops.
  • municipality is the name of the city/municipality in which the stop is located.

Example 1: Groups of stops named “Chrášťany” of different types in different districts (selected attributes only)

<group name=”Chrášťany” districtCode=”RA” isTrain=”true” idosName=”Chrášťany” uniqueName=”Chrášťany” node=”9520″ avgLat=”50.1428″ avgLon=”13.6631536″ municipality=”Chrášťany”>

<group name=”Chrášťany” districtCode=”BN” idosName=”Chrášťany (BN)” uniqueName=”Chrášťany (BN)” node=”4471″ avgLat=”49.7927″ avgLon=”14.5866871″ municipality=”Chrášťany”>

<group name=”Chrášťany” districtCode=”KO” idosName=”Chrášťany (KO)” uniqueName=”Chrášťany (KO)” node=”2410″ avgLat=”50.06581″ avgLon=”14.9295769″ municipality=”Chrášťany”>

<group name=”Chrášťany” districtCode=”PZ” idosName=”Chrášťany (PZ)” uniqueName=”Chrášťany (PZ)” node=”1190″ avgLat=”50.0447922″ avgLon=”14.2591076″ municipality=”Chrášťany”>

Example 2: Stop groups at node 237 (selected attributes only)

<group name=”Karlovo náměstí” node=”237″ avgLat=”50.07532″ avgLon=”14.4185734″>

<group name=”Moráň” node=”237″ avgLat=”50.0740242″ avgLon=”14.41873″>

<group name=”Novoměstská radnice” node=”237″ avgLat=”50.0774574″ avgLon=”14.4195213″>

<group name=”Palackého náměstí” node=”237″ avgLat=”50.07274″ avgLon=”14.4144449″>

Stops (stop signs) <stop>
Each group of stops with the same name contains stop signs.

  • id is the internal stop identifier node number / stop sign number. This identifier is unique within the entire file and does not change between file updates. The node number corresponds to the node value of the stop group.
  • platform is a station code used to identify a column within a group of stops, for example on departure boards
  • altIdosName is a name that may contain a specification, the purpose of which is to further identify a specific stop sign, see example below

<group name=”Anděl” districtCode=”AB” idosCategory=”301003″ idosName=”Anděl” uniqueName=”Anděl” node=”1040″>
<stop id=”1040/1″ platform=”A” altIdosName=”Anděl (ul. Plzeňská)” lat=”50.07193″ lon=”14.40363″ />
<stop id=”1040/2″ platform=”B” altIdosName=”Anděl (ul. Plzeňská)” lat=”50.0719528″ lon=”14.4028063″ />
<stop id=”1040/3″ platform=”C” altIdosName=”Anděl (ul. Nádražní)” lat=”50.071804″ lon=”14.4042273″ />
<stop id=”1040/4″ platform=”D” altIdosName=”Anděl (ul. Nádražní)” lat=”50.0709763″ lon=”14.40455″ />
<stop id=”1040/11″ platform=”K” altIdosName=”Anděl” lat=”50.0717354″ lon=”14.4019508″ />
<stop id=”1040/12″ platform=”L” altIdosName=”Anděl (ul. Stroupežnického)” lat=”50.0715″ lon=”14.4029284″ />
<stop id=”1040/14″ platform=”N” altIdosName=”Anděl (ul. Stroupežnického)” lat=”50.0715179″ lon=”14.4026489″ />
<stop id=”1040/101″ platform=”M1″ altIdosName=”Anděl” lat=”50.06953″ lon=”14.4035711″ />
<stop id=”1040/102″ platform=”M2″ altIdosName=”Anděl” lat=”50.070488″ lon=”14.4048777″ />
</group>

Passing lines <line>
Each stop contains a list of lines that stop there

  • id is the numeric line identifier.
  • name is the line designation used in relation to passengers
  • type is the vehicle type (see XSD for possible values)
  • isNight if the value is true, it is a night line
  • direction is the most common final stop for connections departing from a given stop
  • direction2 is an alternative final stop (does not have to be filled in)

 

PID sales points

The files with the list of points of sale contain a detailed description of all registered places where PID fares are purchased, which includes

  • Ticket machines
  • Selling points at metro stations
  • Information centers
  • Train stations
  • Transit operator offices

The file is available in XML and JSON formats. There is an XML schema for the XML format that describes the format. It is useful to use code lists with texts to display data to users.

Sales points <point>

  • id a unique identifier for the point of sale. It remains the same between file updates, so it can be used for differential updates, for example.
  • services is a bit field of flags of individual services provided by the location. Individual services are listed in the code list.
  • payMethods is a bit field of payment method flags. Specific values ​​are given in the code list.