Stál jsem na Staroměstské, což je jedna z pražských tramvajových stanic, která je vybavena informačním displejem ukazujícím, která tramvaj přijede a za kolik minut. Celkem nic neobvyklého, ale pak jsem si uvědomil, že mám takový ten pocit, že něco není úplně v pořádku. Že mi něco uniká.
Omluvou budiž, že člověk v Praze za nějaký čas otupí, o rodácích jako já ani nemluvě. Došlo mi to až na Pavláku, kde jsem spočinul pohledem na zastávkovém totemu a údaj nikde. Nebylo to poprvé, co jsem si položil otázku, proč to není na všech zastávkách a dokonce si tradičně slíbil, že se zkusím poptat – ale vždycky do toho vlezlo něco urgentnějšího.
Tentokrát se ale do toho připletlo otevření nových stanic metra a „výhružky“, jak se nám Pražákům v dubnu pěkně změní doprava. Což vyvolalo až překvapivě silnou negativní odezvu, takže radní pro oblast dopravy Petr Dolínek návrh odložil na neurčito. U některých návrhů přitom bylo jasné, že automaticky vzbudí odpor. Slovy klasika „Ptám se: Jak je to možné?“
Současná odpověď bývá: zkus Google. Tak jsem učinil a zavolal spolužákovi, který se pro Velkého bratra lopotí, abych poptal, odkud táhnou data pro svoje mapy. A také abych zjistil, na koho se přímo obrátit, protože přes marketing a tiskové mluvčí bývá cesta strastiplná. „No, nevím, co čekáš, ale my máme stejný data jako Seznam“, zněla odpověď, při níž mi trošku poklesla kolena. Seznam totiž pár let soudně válčil s Ministerstvem dopravy s tvrzením, že nedostává potřebná data. „Hele, záleží, nač je potřebuješ, a jak je využíváš. Nám to vyhovuje a dokážeme si je pro naše účely zpracovat.“ A tak jsem byl od Velkého bratra poslán k čertovi, firmě Chaps, která se ministerstvu o data jízdních řádů stará. Ale také například vyvíjí a spravuje Dopravnímu podniku hl. m. Prahy (DPP) systém na tvorbu jízdních řádů. Prakticky jsem očekával odpověď typu: „Všechno je obchodní tajemství, nic vám neřekneme“. I tak jsem se pro jistotu zastavil na dopravní fakultě ČVUT pro informace, jak to v oboru vypadá, aby člověk nevařil úplně z vody. Reakce: „Potěš pánbůh, buď rád že to funguje!“ sice daňového poplatníka znejistí, ale na druhé straně předestření historie vývoje, kdy dopravní systémy jsou složeny z řady řešení různých firem, v různém čase, vysvětluje, proč vše nejde tak, jak by člověk očekával. Překvapivě se ozvali i pánové z Chapsu, že se nad tématem rádi sejdou.
Než přejdeme k tomu hlavnímu, co mě zajímá, tedy jízdním řádům, jaký je stav vašeho sporu se Seznamem?
Pokud mám správné povědomí, tak soudní spory se Seznam.cz byly v „prvním“ kole o potvrzení předběžných opatření, kdy předběžná opatření byla potvrzená. Následná meritorní rozhodnutí vesměs skončila rozhodnutím druhoinstančních soudů, kdy nám daly za pravdu, tzn. soudní spory jsme vyhráli. Seznam.cz se však nově obrátil na Ústavní soud se stížností na postup Nejvyššího správního soudu, takže spory pokračují.
A co správní řízení, které s vámi zahájil ÚOHS?
„Spor“ u ÚOHS je o podnětu Seznam.cz, kdy se domnívá, že CHAPS zneužívá své dominantní postavení. ÚOHS zahájil správní řízení, které nadále probíhá. Nahlédnutím do spisu jsme zjistili,
že Seznam.cz se snaží získat přístup do spisu, zřejmě za účelem získání podkladů pro žalobu o náhradu škody.
V čem je tedy háček? Je to takový problém data poskytnout?
Data poskytujeme tak, jak nám stanoví zákon a jak dokazuje řada funkčních aplikací třetích stran. Je zajímavé, že z řady odběratelů má pouze Seznam takhle výrazný problém. Podle nás jde o to, že Seznam potřeboval data pro svoje řešení v určité struktuře, kterou musí z námi dodaných dat vypracovat, a to ho něco stojí. Takže se snaží o to, abychom mu na vlastní náklady připravili data ke komerčnímu využití. Seznam povýšil svůj obchodní záměr (vybudovat službu, která bude konkurovat jejich konkurentům) na zájem obecný, resp. prezentuje to jako boj o data pro všechny. Primárně ale jde o urvání části „trhu“ na úkor ostatních… My jsme schopni pro ně data připravit, ale to už nemůže být z podstaty věci veřejná služba. Tady jde i o konkurenční boj, např. Google by se mohl ohradit, že zvýhodňujeme konkurenta, apod.
Takže tvrdíte, že Seznam po vás chtěl komerční službu a přitom říká, že byste ji měli poskytnout zdarma?
V podstatě ano, data zveřejňujeme ve formátech, ze kterých, pokud to umíte, resp. máte vůli, veškeré informace získáte. Přirovnal bych to k burze, my dodáme čísla, ale článek do ekonomické rubriky si už musí napsat autor sám.
Tak jsem si zahrál na ďáblova advokáta, ale pojďme k těm číslíčkům, kvůli kterým jsme se sešli dnes, a jejichž výsledkem jsou jízdní řády. Jak to vlastně probíhá?
Jde celkem o jednoduchý proces co do posloupnosti, který je ovšem složitější na zpracování. Je nutné mít na paměti, že DPP je provozní organizace, která funguje podle požadavků Regionálního organizátora Pražské integrované dopravy. To si řada lidí neuvědomuje, ale trasy, odkud a kam apod. si nestanovuje DPP, ale ROPID, jako organizátor Pražské integrované dopravy. DPP je totiž pouze jeden z provozovatelů v rámci PID. ROPID po stanovení tras pošle do DPP a další provozovatele (příměstské, „modré“ autobusy) požadavek na zajištění linek v určitých parametrech a na základě těchto požadavků, zhotoví DPP jízdní řád.
Co tedy vlastě všechno určuje ROPID?
ROPID na DPP zašle zadání ve formě linkového vedení, určí číslo linky, odkud kam vede, v jakých parametrech jezdí, zda je v provozu v sobotu/neděli, i provozní parametry, zda jedou u tramvají jeden, dva vozy, krátký/dlouhý autobus. Součástí zadání jsou i časové polohy spojů, takže je zadáno, kdy jede první spoj z výchozích zastávek, od kolika hodin se má přecházet na jednotlivé intervaly a pro noční provoz jsou zadány například přestupové tabulky, tedy místa, kde na sebe linky navzájem vyčkávají. V případě výlukových jízdních řádů se data zpracovávají přímo v DPP.
A samotný vznik jízdního řádu?
Je potřeba zmínit, že nevzniká pouze jeden jízdní řád – ten veřejný, který zná veřejnost. Tvoří se i vozové, zastávkové jízdní řády i jízdní řád pro řidiče. Základem pro vznik jízdních řádů, podobně jako v řadě dalších odvětví, jsou tradičně číselníky. Například, zastávkové číselníky obsahují informace o zastávkách v síti, zastávkových označnících, jejich popis, kde jsou umístěny, fotografie zastávky, popis přestupů. Další důležitou součástí je správa tras. V rámci sítě jsou zadány jednotlivé trasy mezi zastávkami s uvedením metrů a času. Například, pro autobusovou dopravu je nadefinováno přes 38 430 mezizastávkových úseků. Na základě zadaných tras (odkud/kam) se nám poté z číselníků nabídnou jednotlivé mezizastávkové úseky, které můžeme na sebe postupně navázat, až je hotova celá linka. V podstatě jde o takové puzzle. Výsledkem je chronometráž jednotlivé linky, která je výchozí pro vznik jízdního řádu. Po zhotovení chronometráže je na řadě grafikon, který určí první odjezd z výchozí stanice, intervaly. Zde také zjistíme časové polohy, tedy aby například linky, které jedou část trasy společně, jezdily proloženě apod. Do grafu spoje se zanášejí i informace o bezpečnostních přestávkách a řada dalších provozních dat. Následuje přiřazení výkonů jednotlivým provozovnám/vozovnám. Například se pracuje s takzvanými přejezdovými vozy, kdy, například v nočních časech, aby autobus nestál třeba hodinu na konečné, odjede v té době třeba kratší trasu a vrátí se na svoji původní linku. Když se všechno zanese, zkontroluje se, zda se linky někde nedublují, nepředjíždějí – to jde na jedné koleji značně špatně :), neprojíždějí, zda sedí časy, zda na lince jsou garantované nízkopodlažní vozy, zda se z vozovny nepřiřadilo více vozů, než jich skutečně je apod. To už program nehlídá a vše se musí kontrolovat ručně.
Takhle popsané to vypadá jako hračka, v podstatě se tam nasypou ze zásobníku zastávky, program to spočítá a odškrtáte si kontrolní položky. Jak dlouho tedy trvá připravit podobnou změnu, jaká byla plánována na duben?
I když to tak vypadá, tak jednoduché to není. S programem pracuje konstruktér, který musí mít obrovské zkušenosti, znalosti dopravní sítě, provozních podmínek apod. Připravit podobnou celosíťovou změnu trvá přibližně měsíc, ale i když jsou takto rozsáhlé celosíťové změny pro veřejnost nejviditelnější, nepředstavují největší objem činnosti. Jízdní řády se mění doslova denně. Zasahují totiž do toho krátkodobé výluky, při kterých musíme připravit změnové jízdní řády. Největší problém není v grafikonech jako takových, ale návaznostech. Například nyní máme připravený jízdní řád do 12. března (rozhovor vznikal v únoru, pozn. autora), a v tuto chvilku je to již 42. provozní změna v jízdních řádech v letošním roce. Linka také může při výluce končit například na kolejovém přejezdu, takže se na linku musí nasadit oboustranné vozy, které jezdí na jiných linkách, ale kvůli této změně musí být nasazeny zde. Takže změna se nedotkne pouze jízdního řádu na dané trase, ale představuje změnu ve vozových jízdních řádech na dalších cca 10 linkách, odkud se budou tyto vozy stahovat.
Takže jízdní řád máme, co se s ním děje dál?
Jízdní řád, respektive grafikon, je uložen do databáze DIS (Dopravní informační systém). Jde o jednotný systém pro celou PID, kdy existují dva servery, dvě shodné databáze na DPP i ROPIDu. Mezi nimi se vyměňují informace, takže obě strany vidí schválené oficiální grafikony opačné strany. Z databáze se generují výstupy podle jednotlivých požadavků – odcházejí jízdní řády (vozové, řidičů), avíza o změnách a některé další informace pro jednotlivé druhy dopravy, které je využijí v rámci svých informačních systémů nebo přímo vytisknou – ISP (informační systém provozovny), VV (výkony vozidel metra), AUDIS (dispečink autobusy), DORIS (dispečink tramvaje), ASŘ Metra, odbavovací a informační systém o vozidlech. Z databáze se generují podklady i pro webové portály, generují PDF řády platné pro dané období a data poskytovaná ve formátu GTFS. Proti předpokladu veřejnosti se v databázi kvůli zanesení změn a provázanosti, nevyskytují linky v pevné podobě. Tedy v databázi není spoj popsán tabulkou, že v 10:30 je zde, v 10:35 zde a v 10:37 tady, ale je počítán podle výchozích údajů. Spoj je zde popsán odjezdem a trasou, kdy projíždí podle chronometráže úseků, takže jeho jízdní doba je již daná, a průjezdy se dopočítávají na pozadí. V případě změny se tak projeví do jízdní doby automaticky (přepočítají se podle mezizastávkových úseků) a není potřeba přepisovat, respektive popisovat celou linku znovu, jak by bylo nutné v případě tvrdých dat. Do dat pro vyhledávače se doplňují pěší trasy (přestupy), aby dokázal propojit jednotlivé linky, k některým zastávkám je přiřazován pro komfort ještě pseudonym, nebo dlouhodobě používané označení, které je odlišné od oficiálního názvu zastávky. Samozřejmostí je také generování datového souboru do CIS (Centrální informační systém o jízdních řádech).
Předpokládám, že s jízdními řády a informacemi souvisejí i ukazatele na informačních tablech na zastávkách. Proč je to jenom někde, a existuje nějaký důvod, proč v Praze není aplikace, jakou má DPMB, kde vidím v reálném čase, kde se spoj vyskytuje?
Tady se opět vrátíme ke vztahu DPP a ROPID. V rámci organizace DPP existují systémy pro jednotlivé druhy dopravy a zastávky jsou provozovány v jejich rámci. Historicky provozuje pro DPP tyto systémy označené jako AUDIS a DORIS jiná společnost. A záleží, kdo je provozovatelem zastávky. V případě příměstské dopravy jde o zastávky ROPID, pokud je to tramvaj nebo autobus, jde o zastávku DPP. A každý provozovatel bere data pro své panely z jiného zdroje. Na zastávce v Praze se zobrazují data z AUDIS/DORIS, které pracují s informacemi o poloze vozu zaslané vůči jízdnímu řádu, kdy lze jednoduše odvodit jaké zpoždění, či pořadí budou mít jednotlivé vozy. Nicméně takovéto informace nejsou mimo tyto systémy poskytovány tak, aby bylo s nimi možné pracovat. V podstatě je to tak, že pokud dodáme do zmíněných systémů naše data o jízdních řádech v otevřeném formátu, dokáží s nimi tyto části pracovat. Ale již neexistuje řešení, které by převedlo informace z těchto systémů do volného formátu. A v případě ROPID lze u jejich zastávek data o aktuální poloze na internetu dohledat. Tam zajišťujeme trasování vlastním MPV (Monitorování provozu vozidel), které umožňuje sledování vozů v reálném čase a průběžné řešení provozních situací, takže dokážeme zobrazit informace o stavu na informačních panelech nebo internetu.
Takže mi říkáte, když to přeženu, že jde o stejný model jako má DPP a EMS? Že data jsou, ale neexistuje rozhraní, které by umožnilo je interpretovat mimo nastavené struktury?
Takto bych to skutečně neviděl. V tomto případě jde spíše o technickou problematiku jako je zabezpečení komunikace, časové prodlení apod., které se musejí nejdříve vyřešit. DPP má data rozhodně pod svojí kontrolou. Problém vidím spíše v obecné rovině finanční náročnosti zavedení potřebných změn a technologií. Bohužel schvalování a posuzování projektů je věc zdlouhavá, zvláště dnes, kdy obrátíte každý list papíru raději pětkrát a desetkrát vše prověřujete, abyste vyloučil, že jde o projekt „pro kamaráda“. Což je i správné, ale platí se za to menší flexibilitou.
