Problém je, že kdyby si Seznamu za poskytnutí dat řekli o přiměřenou část z těch tří člověkoroků, tak by nikdo ani nepípl, protože umí počítat. Jenže když si řeknou třeba o dvacetinásobek a to *každému* zájemci, pak to je sprosté vydělávání na monopolu. Notabene, když ty data dostanou od státu a sami je nevytvářejí (avšak evidentně si myslí, že si mohou naúčtovat i vznik těch dat).
S nápadem problém není - vyhledávat spojení, podobně jako to dělají stávající aplikace, ale lépe. Prostor na zlepšení tu je:
o Lépe pracovat s přestupy. Čas přestupu závisí na detailní trase přestupu (aplikace by ji měla umět detailně popsat), aktuálních dispozicích cestujícího a (pěší) dopravní situaci v daném místě a čase. Zohlednit je potřeba časy navíc, jako je jízda výtahem, nákup lístku apod.
o Zohlednit aktuální situací (tj. zpoždění, zácpy, výluky apod.) při hledání spojení v aktuálním čase.
o Usnadnit dohledávání dalších variant spojení (tj. nejen drobné posuny v čase, ale i prostoru apod.)
Jiná úloha je hledání vlaků, kdy většina zastávek je na svém místě už 150 let a hledání v pražské MHD. Situaci, kdy alternativně mohu jet přes 5 zastávek v okruhu 200 m, z niž některé se jmenují stejně a jiné ne, některé jsou na stejných souřadnicích, ale 30 m hluboko, nezvládá dobře žádná aplikace. Vždy jsem musel ručně zkoumat různé dílčí úseky, abych získal přehled, kde co pojede.
Naštěstí se to vyřešilo brutální hw silou - přímým metrem za 20 miliard.
CHAP má monopol na data od státu. Vznik dat od státu jsem zaplatil já i všechny firmy v podobě daní a je tudíž nesmysl je "prodávat". Pokud někdo ty data učeše a odstraní chyby, má nárok na odměnu. Avšak když nikdo jiný data nedostane, tak si logicky monopolní CHAPS diktuje cenu, která neodpovídá vložené práci (tj. nepřiměřený zisk). Nikdo CHAPSu jim tu práci (a odměnu) nebere, jenže by za to měla být částka nižší, než kolik bych vydal, když bych stejnou práci udělal sám (jako např. Seznam, když parsoval dostupná PDF), protože logicky platících zájemců bude více. Další věc je, že monopol nepřinesl za těch 20 let vůbec nic. Já jako zákazník nemám offline data, podle kterých bych si spoj vyhledal. Nemám možnost si rovnou koupit/rezervovat lístek. Výsledkem je, že radši pojedu autem, což je úplně špatně - v zájmu např. Českých drah by mělo být, aby kdokoliv mohl spoj vyhledat a oni tak získali cestujícího. Jenže je to obráceně a tím pádem ryba smrdí od hlavy. Prostě si z toho nějací kamarádíčkové dělají byznys, místo aby přišli na způsob, jak skutečně a samostatně vydělávat (např. při podílu z ceny prodané jízdenky, což by bylo férové).
Sice jde o soukromou firmu, ale ty data za normálních okolností nejsou jeho. Pouze je spravuje. Ministerstvo by to spravovalo samo, ale nechtělo se mu, tak se dohodl s CHAPSem, že to bude dělat on. Jenže MD mu správu nechtělo ani platit, tak si z toho CHAPS udělal vlastní byznys. No a celé se to pak zamotalo a dostalo do takové absurdity. Kdyby MD nedělalo takové šaškárny a vše důkladně ošetřilo, tak by nebyly takové problémy a data by byla otevřena.
Sice to není formální standard, ale je to faktický standard, ve smyslu, že import těch data je podporovaný v několika opensource routerech, existují nástroje pro import do OSM, editory apod.
https://code.google.com/p/googletransitdatafeed/wiki/OtherGTFSTools
Jiný nápad: Zaměřit se více na trasy a méně na konkrétní spoje. Pokud se z místa A do místa B můžu dostat s přestupem na Kačerově, na Roztylech a na Opatově, tak víc než nějaký konkrétní spoj mě zajímá, že z Kačerova to jede každých 10 minut, z Roztyl každých 20 a z Opatova jsou 4 spoje během 5 minut a pak půl hodiny nic. A je mi úplně jedno, jestli je to stejné číslo linky nebo různá čísla ... a na tom už vyhledávač naráží, ten považuje číslo linky za nejdůležitější. Já ne. Protože když náhodou na schodech zakopnu, rozsypu tašku, minutu ji sbírám a přípoj mi ujede, tak je pro mě sakra důležité, jak moc se zdržím čekáním na další.
Ze současných vyhledávačů tohle dostat, to je pomalu na stažení několika stránek do databáze a vyhodnocování všech nalezených možností.
Toto mi je také nejasné. Proč si stát (zákonem, vyhláškou)/kraje doposud nedefinovali jednotný formát jakým způsobem budou závazně publikovat/vyžadovat data pro jízdní řády? Když se podívám zpětně, tak jsou asi 2 způsoby jak vypadají jízdní řády a je několik různých značení spojů.
Ze znalosti věci v tom vidím okruh firem a státních institucích zapojených v tomto dopravním byznysu. Chaps je taková firmička vzniklá kolem lidí od firmy Oltis (Chlebničan/Mestický), Chaps i Oltis fungují jako opravdu hodně velký dodavatel IT technologií pro společnosti poskytující dopravu, například České dráhy, a.s. mají systém pro rezervační portály nebo třeba dispečink od Oltisu, Chaps třeba dodával Můj vlak. SŽDC to samé. V tomhle státem dotovaném byznysu se musí točit neuvěřitelné množství peněz v řádech stamilionů.
Když můžou v GTFS publikovat jízdní řády desítky měst nejen v USA, ale i Nizozemí, Švédsko a mnohé další, proč by to nemělo jít u nás?
https://code.google.com/p/googletransitdatafeed/wiki/PublicFeeds
Nevim, co vsechno v tom formatu je, ale vidim, ze evidentne k necemu pouzitelny je, kdyz to v nem publikuje tolik zemi. Navic diky tomu, ze je standardni, existuji napr. nastroje pro import techto dat do OpenStreetMap a patrne i jine dalsi zpracovani.
Navic pokud tam chybi treba prestupni casy, lze je bud doplnit nejakym rozsirenim toho formatu, nebo alespon jako nouzove reseni si dovedu i predstavit nejake priblizne dopocitani pomoci vzdalenosti jednotlivych stanic a jejich typu.
Mně spíš vadí, že u těch přestupů se občas vloudí velké chyby. Například mi to našlo spojení z Prahy 9 na letiště podivným směrem a po pořádném prohlédnutí jsem zjistil, že tam byl pěší přestup Ládví - Divoká Šárka. Být mimopražský, tak bych to asi zjistil až když by mi uletělo letadlo.
Z toho podle me vyplyva, ze data musi byt zverejnena tak, jak je tam Ceske Drahy poslaly, coz je ten .TXT format a zadne PDF.
To víte odkud, že SŽDC data do CIS JŘ posílá ve formě nějakého TXT souboru? Formát JDF je určen pro autobusovou dopravu. PDF železničních jízdních řádů jsou PDF vytvářená SŽDC, takže to "žádné PDF" určitě neplatí.
Dávnejšie som sa s tým hral, tu je návod:
https://uzivatel.wordpress.com/2015/02/21/vyhladavanie-spojenia-gtfs-opentripplaner/
Milé j, jak je vaším dobrým zvykem, pletete se úplně ve všem – a změna přezdívky na tom nic nezměnila. Zřejmě o tom nevíte, ale České dráhy jsou především železniční dopravce. Veřejnou dopravu v ČR řeší dva zákony, jeden řeší autobusovou dopravu, druhý železniční. V případě autobusové dopravy to funguje tak, že dopravce předává jízdní řád dopravnímu úřadu (krajský úřad), který uděluje licence – a tento úřad schválený jízdní řád postupuje dále do CIS JŘ. Na železnici to funguje trochu jinak, protože tam si jaksi nemůže každý dopravce udělat svůj jízdní řád nezávisle na ostatních. Na železnici tedy dopravci žádají o trasy, ale rozhoduje o tom a tedy sestavuje jízdní řád správce infrastruktury, nebo-li SŽDC. Logicky pak jízdní řády do CIS JŘ nedává dopravce, ale SŽDC.
Způsob předávání dat jízdních řádů autobusů nestanovuje zákon, ale vyhláška, konkrétně 122/2014. Přičemž tato vyhláška samozřejmě neříká, že se data zasílají v libovolném elektronicky (asi jste myslel strojově) zpracovatelném formátu (protože to by každý dopravce mohl poslat v jiném formátu), ale říká, že dopravce data předává jízdní řád současně v elektronické podobě v datovém formátu a v datové struktuře, které zveřejní ministerstvo (§ 6, odst. 3).
S jízdními řády vlaků je to komplikovanější, protože zákon se původně také odkazoval na vyhlášku, jenže vyhláška byla novelizována a nová vyhláška platí pouze pro jízdní řády autobusů. Nebo-li v případě železniční dopravy vyhláška formát nestanovuje ani nikoho nezmocňuje k jeho stanovení. V tomto případě je tedy v legislativě díra, o které se ostatně píše i v článku.
Jenom na okraj dodávám, že i do PDF se dají dát data tak, aby byla strojově zpracovatelná. Dokonce je možné do PDF vkládat jiné soubory, takže když na to přijde, můžete mít PDF s jízdním řádem čitelným pro člověka, a v něm vložený soubor (třeba CSV nebo XML), který bude strojově zpracovatelný.
No já hlavně reagoval na větu "A standardní celosvětově univerzální formát pro jízdní řády bych radši ani nechtěl vidět..".
Když takový formát existuje a používají ho celé státy i desítky měst, tak asi zas tak špatný nebude. A přestupní vazby pochopitelně umí: https://developers.google.com/transit/gtfs/reference#transferstxt
Myslím, že nejčistší řešení by bylo, aby dopravci data posílali tak, jak je mají na MD, to by je publikovalo a zároveň by mohlo vypsat veřejnou zakázku na zpracování těch dat a publikování v GTFS. A se CHAPS klidně přihlásí, pokud mají tak unikátní knowhow, jistě to hravě vyhrajou.
Ale jo, když vystoupí nahoře z těch správných dveří (u eskalátoru), celá trasa bude vylidněná a "popoběhne si" ve smyslu "celou dobu sprintem", tak to dolů za minutu nejspíš zvládne... Ten argument asi správně zní "Když existuje (teoretická, laboratorní) možnost to za minutu dát, tak v reálu přece musí trojnásobek stačit každému."
Za prvé, jeden příklad nedokazuje, že jsou ty přestupy nesmyslné v nezanedbatelném množství případů. Za druhé, na přestupy na Florenci a na Můstku počítá Idos 3 minuty, pouze na Muzeu 2 minuty. A alespoň na Florenci trvá přestup minutu, pokud si člověk popoběhne, takže za 3 minuty to stihne i člověk, který se loudá.
Proc by probuh soukroma komercni spolecnost poskytovala zdarma data, v nichz ma kazdy rok tri clovekoroky sve vlastni vyvojove a kontrolni prace? To si skutecne cela republika androidovych kutilku srackovych aplikaci mysli, ze data tecou od ceskych drah a vsech dopravcu presne v tom formatu, ktery oni pro svou mikroaplikaci potrebuji? Ze kazdou vyluku spoje, kazdou nahradni dopravu apod. dostanou z nebe jen tak zadarmo? K cemu bude celemu narodu jejich stupidni krasne graficky provedena aplikace se spolehlivosti 88.4%? No nic, preju vasnivou a hlavne zasvecenou diskuzi.
Tak zrovna ten slavny idos uvadi v pripade prestupu casy zcela nesmyslne. Opravdu chci videt sprintera, ktery zvladne zcela bezne prestupy kuprikladu v metru za 2 minuty. A podotykam, ze se to da, ale dotycny musi pri prijezdu na prestup stat u zcela konkretne vybranych dveri, musi z nich vystartovat, celou dobu vcetne pripadne jizdy po schodech bezet a ve finalnim stadiu mit tu kliku, ze mu souprava neujede pred nosem.
A zcela pochopitelne, na trase presunu nesmi byt zadni dalsi lide.
Jak se v GTFS vyjádří například čekání na přípoje? Jak různé doplňkové služby? Jak příslušnost zastávky do více tarifních zón, případně rovnou do více tarifních systémů? Jistě že se pomocí GTFS dají základní informace z jízdních řádů využít, ale proč další informace z jízdních řádů vyhazovat, když už tam jsou? Respektive jak konkurenceschopný by asi byl vyhledávač, který by pracoval s touhle omezenou sadou informací, v porovnání s Idosem, který má ta data všechna? Ono vůbec bude zajímavé, až autoři po opadnutí prvního nadšení ze zveřejnění dat zjistí, že jsou to opravdu jen jízdní řády, a polohy stanic nebo pěší přestupy má pouze Chaps, protože to není součást dat jízdních řádů.
Ano, k něčemu použitelný je, jenže proč chtít jenom něco, když máme data na něco lepšího? Navíc data se zveřejňují v tom formátu, v jakém je Chaps dostává, takže tam není žádný prostor pro jejich pokažení, všichni mají stejné podmínky, a s tím publikováním by neměly být prakticky žádné náklady. Vaše řešení by dávalo smysl, pokud by se začínalo na zelené louce.
Já jsem pro to, aby se používaly otevřené standardní formáty. Ale tady dávám přednost tomu, že se zvolilo rychlé levné řešení, které je výrazným posunem vpřed oproti současnému stavu. A dovedu si živě představit, že kdyby se řešil jiný formát, než ten stávající, nakonec to v GTFS stejně nebude, zato by stát vypsal další velkou IT zakázku na systém pro řízení zeměkoule, žádosti o jízdní řády byste podával osobně v Šumperku na 30stránkovém formuláři podepsaném vlastní krví a jízdní řády by chodily pouze formou změnových souborů od začátku roku do datových schránek.
Ty celé státy a desítky měst ten formát používají jako primární formát dat a bez nějakých rozšíření? Nebo ze svých bohatších formátů poskytují export i do tohohle formátu?
Není mi moc jasné, proč by měl stát řešit publikování do GTFS – vždyť si to může udělat ten, kdo data v tomhle formátu potřebuje.