Data jízdních řádů ke stažení

Ke stažení

Sloučené celostátní jízdní řády ve formátu GTFS (viz popis níže) jsou dostupné na:
https://www.spojenka.cz/jrdata/jizdnirady-gtfs.zip

Původní databázi se všemi údaji ve formátu Kryo k použití s kompatibilními knihovnami, případně pro vytvoření filtrovaného exportu nástroji Spojenky, lze stáhnout na:
https://www.spojenka.cz/jrdata/jizdnirady-kryo.ttblob

Popis

• Formát: GTFS (specifikace, rozšíření PID)
• Datum aktualizace: Načítání...
• Velikost souboru: Načítání...

Obecné

Data v GTFS jsou generována v základní specifikaci se soubory:

• agency.txt
• calendar.txt
• calendar_dates.txt
• levels.txt
• pathways.txt
• routes.txt
• stop_times.txt
• stops.txt
• trips.txt

Dále jsou přítomna některá rozšíření použitá v open datech systému PID, konkrétně:

• is_substitute_transport v routes.txt
• max_waiting_time v transfers.txt
• exceptional v trips.txt

Dataset je po větších změnách kontrolován validátorem.

Identifikátory záznamů

Veškeré záznamy, které disponují stabilními identifikátory (linky, spoje, zastávky) je mají uvedené v GTFS jako řetězce ve formátu REGISTR:identifikátor|..., kde svislice odděluje čísla v různých registrech (pokud by náhodou identifikátor sám obsahoval svislici, bude odescapovaná zpětným lomítkem \). Dodatečně mohou být přítomny rozlišující informace, které jsou odděleny tečkou. Třeba u spojů je takto oddělena část týkající se linky od části týkající se spoje, u zastávek se podobně rozlišují nástupiště a tarifní zóny. Pokud daný záznam neobsahuje stabilní identifikátor, bude mu přiřazen dočasný, který lze rozeznat tak, že nebude mít předponu s kódem registru.

Tarifní zóny

Formát GTFS nepodporuje specifikaci tarifních zón tak, aby mohla jedna zastávka patřit do různých zón v závislosti na lince. V tomto případě se jedná spíše o krkolomnost některých tarifních systémů než nedostatek na straně formátu, nicméně s tím nejde nic moc dělat, takže i toto chování je zde emulováno podobně jako v GTFS datech PID vytvořením duplikátů zastávek pro různé možné zóny. Duplikáty lze sloučit dohromady podle shody souřadnic nebo identifikátorů (liší se pouze rozlišujícím polem .Z###, které reprezentuje použitou kombinaci zón).

Nejednoznačnost čísel zón mezi tarifními systémy je řešena obdobně jako u formátu JDF přidáním předpony IDS podle kódovníku.

Názvy a čísla linek/spojů

Linky jsou zpravidla číslovány lokálními čísly v IDS. V případě, že jich je více, jsou oddělena lomítkem. Definice rozsahu trasy, kde spoj obsluhuje danou linku, není formátem GTFS podporována, a tudíž není přítomna.

Speciálně linky vlaků také mohou obsahovat jejich názvy (Berounka, Lužnice, Vysočina, Metropolitan). V případě, že je jedna linka (třeba Ex1) obsluhována vlaky s různými názvy, budou pro ni vytvořeny oddělené záznamy.

Pokud linka nemá žádný zkrácený název, je použito číslo z některého z registrů. Pokud neexistuje ani takové číslo, je pojmenována podle své trasy (počáteční a koncový bod).

Vlakové spoje mají v poli trip_short_name uvedené své číslo. Je-li takových čísel víc, jsou oddělena lomítkem. Čísla odklonových tras (třeba 100777 pro vlak 777) jsou vynechána.

Dopravci

Dopravci jsou v GTFS reprezentováni souborem agency.txt. Na ně jsou navázané konkrétní trasy, z čehož vyplývá, že stejná linka obsluhovaná více dopravci bude mít pro každého separátní záznam (obdobně jako tomu je s licenčními čísly CIS JŘ). Struktura je tedy v tomto podobnější datům IDFM spíše než pražským nebo brněnským.

Dopravci jsou identifikováni podle IČO nebo DIČ, jsou-li tyto údaje dostupné. V takovém případě mají ID předponu ICO:[kód státu] nebo DIC: (u DIČ je kód státu standardní součástí údaje). Jinak je jim přiřazen dočasný identifikátor ve formátu A####.

Posun kalendáře

Vlaky v jízdních řádech Správy železnic mají kalendáře jízdy počítané ode dne příjezdu do první zastávky na území ČR (v tzv. referenční den). Pokud je v JŘ tedy zahrnuta i nějaká zastávka dříve než v tomto bodě a zároveň tuto zastávku vlak navštíví dříve než v referenční den (typicky noční vlaky), bude mít nastavený negativní "offset", oproti referenčnímu datu pro kalendář jízdy. Tento jev nelze v GTFS reprezentovat, neboť vyžaduje ve všech bodech trasy, a tedy i v prvním, od nějž se rovněž odvíjí kalendář jízdy, nezáporný časový údaj. Proto jsou u těchto vlaků kalendáře o patřičný počet dnů automaticky posunuty, aby byly všechny časové údaje platné. Na přímou interpretaci dat tato změna nemá vliv, nicméně způsobuje neshodu s tištěnými jízdními řády, které uvádějí pevné kódy ve vztahu k původnímu referenčnímu dni.

Cesty mezi nástupišti a nástupními oblastmi

V pražských GTFS datech jsou ve stanicích metra definované vedle nástupišť také tzv. nástupní oblasti. Ty jsou potřeba pro přesnou navigaci, neboť nástupiště jsou dlouhá a způsob přestupu se může lišit v závislosti na tom, kde vystoupíte (třeba na Muzeu). GTFS předpokládá, že mezi těmito nástupními oblastmi a nástupištěm existuje jistá implicitní vazba definovaná relací v souboru stops.txt (parent_station_id), nicméně pro snazší propojení mezi jízdním řádem a geografií stanic v grafových algoritmech jsou v převedených datech navíc zahrnuty "virtuální" hrany nulové délky (algoritmy v důsledku počítají s "optimální" přestupní trasou, tedy např. při přestupu z B na C na Můstku prostřední vagon). Pokud tyto hrany nechcete, můžete je jednoduše odstranit - mezi nástupišti a nástupními oblastmi jiné než tyto nejsou.