Érdekes a kérdés. Pont most próbálom a megváltozott adatbázishoz igazítani a korábbi lekérdezőm funkcióit. Útvonalkód alapján kilistázni az megállók forte kódját és nevét, kifejezetten macerás mutatvány. Egyelőre nem is megy.
Egy szakmai kérdés: A BPI-779 féle lekérdező tisztán SQL lekérdezéseket használ, vagy van benne programozás is? Csak azért kérdezem, hogy van értelme próbálkozni hasonló eredményt elérni mezei SQL lekérdezésekkel, vagy esélytelen?
Érdekes a mai GTFS, van benne egy(?) menet a stop_times.txt-ben A88866106J azonosítóval Szentendre és Szentendre kocsiszín (kapu) között ami hiányzik a trips.txt-ből. Mivel ez egy nem meghirdetett menet, gondolom véletlenül kerülhetett be a stop_times.txt-be.
"Nem lehetne megoldani, hogy a BKK menetrendi oldalon meghirdetett végállomások szerint lehessen irányt állítani?"
Neeeeee! Azokat a meghirdetett végállomásokat kézzel adjuk meg és nem is mindig sikerül a megállókat e két irány alapján szelektálni (ha sietve kerül fel egy hurokjárat, akkor az oda irány a hurokból kilépő megállóig sorolja a megállókat, míg a vissza irány ugyaninnen az induló állomásig. Amint fejlődik a program és az automatizmus, akkor a két irány így fog kinézni:
- oda: induló állomástól a hurokból kilépésig,
- vissza: hurokba belépéstől induló állomásig.
Azaz ebből sem lehet megállapítani majd a meghirdetett végállomást, azt továbbra is kézzel kell majd beállítanunk, de legalább a tájékoztatás a lehető leglogikusabb lesz.
Arra is szeretném felhívni a figyelmet továbbá, hogy van egy-két hurokjáratunk (és ez alapján bárhány lehet), amelynek meghirdetett végállomása különbözik a fellelhető megállókétól. Pl. 136E járatunknak nincs "Havanna utcai lakótelep" megállója.
Érdekes önálló feladat lenne az adatbázisból ilyen szöveges leírásokat generálni, ugyanígy a napi változásokról is. Tájékoztatásnak is jó, plusz az esetleges hibás adatok is jól láthatóvá vállnak.
Most vettem észre, hogy a körforgalmi járatoknál (pl.: a 98, 276E, stb.) a FORTE indítási jegyzékben használt oszlopok szerint lehet végállomást/irányt váltani, ami miatt pár ismerősömnek nehézkes a megfelelő megállókat kedvencként beállítani. Nem lehetne megoldani, hogy a BKK menetrendi oldalon meghirdetett végállomások szerint lehessen irányt állítani?
A jelenlegi megoldás információim alapján ideiglenes, kényszer alapú. Talán többen észrevettétek, hogy volt egy invalid feed-ünk, ami számomra ismeretlen hiba miatt született és amit a vállalkozó így tudott javítani.
Attól, hogy ez ideiglenes, úgy látom, ismét tisztázni szükséges: a feed a Google Térképen történő megjelenés érdekében készül. Mivel az ehhez szükséges GTFS nyílt forráskódú, ezért a feed közzétételével fejlesztők bármekkora tábora látható el adattal különösebb kommentár nélkül. Az, hogy egy fejlesztő általános menetrendi tájékoztatót akar a GTFS-ből készíteni, nem az adatszolgáltató baja. A feed nem erre való. Az, hogy lehetne erre való, még nem jelenti azt, hogy a szolgáltató néhány fejlesztő kedvéért ebbe az irányba megy. A szolgáltatót egy rakás szerződés köti, nem mindig tud logikus irányba fejlődni. Ezen túl pedig a szolgáltató törvényi kötelezettségének eleget tesz a béna PDF megállóhelyi menetrendek közzétételével, amit akkor is köteles megtenni, ha valaki önszántából a GTFS-ből gyárt hasonlót (nyilván jobbat).
Tehát a BKK nem egy hobbista fejlesztő csapat, törvények és a menetrend meghirdetésénél sokkal tágabb tartalmú szerződések kötik. Fejlődése során több millió utas érdekeit köteles (!!!) figyelembe venni, nem pedig réteg igényeket követni (ész nélkül).
Ami a jó hír, a már említett ideiglenesség, továbbá az, hogy konkrét (belső) igény van a menetrendi tájékoztatók GTFS alapú generálására, így a megfogalmazott elvárásoknak lehet, hogy egy év múlva fentiek ellenére eleget tudunk tenni.
Elfogadom, tényleg működik a dolog, tényleg szabványos.
Én csak annyit akartam mondani, hogy a mostani forma szerintem nem "helyes" (vagy nem szép).
Összefoglalva dolgot, vagy inkább azt írom, hogy "ha én készíteném a feed-et, a tökéletes körülmények között":
- Mindenképpen használnám a calendar-t, calendar_dates-et is. Budapesten a járatok a menetrendek alapján (lásd a menetrend lapokat) szépen illeszkedik ebbe a modellbe. Van például hétfőtől-csütörtökig egy menetrend, pénteken, és hétvégén. Vagy van egy másik hétfőtől-péntekig és hétvégén semmi. És ezek a menetrendek ismétlődnek hétről hétre. Ez szépen leírható a calendar-ban, az esetleges kivételekkel együtt a két táblás ábrázolásban. További előnyeit lent ecseteltem. - A Google ezt a modellt ajánlja, bár meghagyja a másikra is az opciót. Ez gondolom a nem ilyen szabályos menetrendekkel operáló városoknak lenne jó. - Eddig működött a két táblás modell, mi az oka, hogy áttérünk az egy táblásra? [*] - Ha valamiért át kell térjünk az egy táblás leírásra, hagyjuk meg üresen a calendar-t (a .txt-ben csak a header sorral). Ekkor a végfelhasználónak egyértalműbb a dolog: én is egyből a hiányra gondoltam, eszembe se jutott megnézni a calendar_dates tartalmát. A GTFS specifikációban is így vezetném be (lehet, hogy fordítva rontották el: a calendar required tényleg, csak a calendar-t nem elhagyhatod, hanem üresen hagyhatod :). - Az hogy más város is így csinálja, elég szomorú. Eddig "mi" biztos nem így csináltuk, tehát térjünk vissza régi útra. Bár Peti817172M kolléga írta, hogy régen is voltak furcsaságok, de akkor én azt az irányt fejleszteném. [Talán a forgalmi számok nem ismétlődnek hétről hétre, az rondított bele a rendszerbe?]
Véleményem szerint egy jól beállított GTFS adatbázisból elég szép mennyiségű plusz információ nyerhető, próbáljunk arra menni, hogy ez így legyen. Most ez a téma apróság, de azért mégis valami!
[*] A BKK-nál lehet, hogy jó okuk van valamiért tényleg így kidobni az adatbázist és nem lesz tartós. Ez esetben legalább megbeszéltük ezt is...
A jelenlegi megoldás szabványos, ugyanis a specifikáció megengedi, hogy hiányozzon a calendar.txt (hiába required, ha alatta egyértelműen írja, hogy nem kell - ez csak egy figyelmetlenség lehet a spec. írói részéről). A hivatalos feedvalidator is elfogadja a calendar.txt nélküli feedeket, és sok más város van, ahol szintén kihagyják, tehát ez nem csak a BKK sajátossága. Az adathalmaz tartalmilag helyes így is, hiszen jól definiált, mit kell tenni ebben az esetben (hogy mik a mezőnevek, az nem igazán számít ebből a szempontból).
Az, hogy jó vagy logikus-e ez a megoldás, már más kérdés. Teljes mértékben egyetértek abban, hogy sokkal jobb alkalmazásokat lehetne fejleszteni, ha a fontos kis apróságok nem vesznének el út közben a GTFS limitációi miatt, illetve nem kellene találgatni, ha ezeket az extrákat ki szeretnénk nyerni a jelenlegi adatbázisból. Viszont ez nem újkeletű dolog, már évek óta ez megy, csak mindig más adatokkal. A probléma, hogy a GTFS eleve nem arra van, hogy az egy-egy városban releváns összes adat benne legyen, hanem hogy egy nagyjából általános szerkezetet adjon, ami elegendő útvonalak tervezéséhez, és a közlekedési társaságok minél kisebb ráfordítással elő tudják állítani (ugye néha már az is csoda, hogy foglalkoznak vele, szóval ez fontos szempont). Ráadásul a célközönség sem mi vagyunk, hanem a "nagyok", akik valószínűleg nem is használnák fel ezeket az adatokat. Ebben a topikban is voltak korábban olyan megnyílvánulások, hogy egy megállóhelyi menetrend és egy útvonaltervező tökéletesen elég, szóval kétlem, hogy komoly előrelépések lennének ezügyben.
Őszintén ilyen mélyen nem tanulmányoztam a dolgot, csak a hiánya volt feltűnő.
A hatékonysági szempont az a végfelhasználónál releváns. Tehát ha én úgy látom, hogy nekem hatékonyabb csak a calendar_dates-el dolgoznom, akkor úgy alakítom ki az én saját adatbázisom.
Viszont a feeder-nél ne legyen optimalizálva ilyen szinten a dolog, ott legyen egy általános szempontrendszerű, és egy általánosan felhasználható adatbázis publikálva. Aztán otthon mindenki eldönti magának, hogy neki hogyan is jó és annak függvényében átalakítja, optimalizálja magának.
A probléma az, hogy már eddig se lehetett egyértelműen eldönteni, hogy kivétel, vagy sem, mert volt hogy a hétfő-csütörtöki és a pénteki menetrendet is hétköznapinak volt tekintve, és a calendar_dates-ben volt kettébontva. Abból a szempontból jó, hogy egy egysoros lekérdezéssel lekérdezhető, hogy melyik nap melyik menetrend van érvényben, ellentétben az eddiginél, ahol kellett egy jó komplikált lekérdezés, majd annak az eredményével még egy lekérdezés, hogy nézzen is ki valahogy a dolog.
Hatékonyság szempontjából előnyös, mert eggyel kevesebb importálandó tábla. Ha a 4 millió soros stop_times tábla feldolgozásához hasonlítjuk, elenyésző a többlet processzorigény.
Meg lehet csinálni. Ha sikerül nagyon jó szabályrendszert felállítanom (erősen kérdéses), akkor reprodukálni tudom a régi struktúrát.
De akkor ott van egy harmadik ember, aki más információhoz jutott a két táblából. Mondjuk csak olyan kivételeket gyűjtött, amik a calendar által meghatározott időintervallumok közé estek, és ezekből csinált valamit. Ő milyen szabályrendszert állítson fel?
És egyébként is miért nekünk kellene szabályrendszereket felállítani és "kézzel" visszanyerni az eredeti formát, amikor eddig sikerült normálisan gyártani ezeket az adatbázisokat?
---
Ahogy egyre többet beszélünk róla az az érzésem, hogy sikerült egy a szabvány által megengedett "kiskaput" találni, hogy egyszerűbb legyen a feed-et publikálni. Csak hahó, ez a feed-forma lehet, hogy szintaktikailag helyes, de szemantikailag nem. Hibás a tartalma. (Bár a calendar.txt hiánya miatt szintaktikailag sem helyes.)
Szóval jó lenne ha a BKK is úgy publikálná a GTFS adatokat, ahogy mindenki. Ahogy a Google kitalálta, lehet van némi rutinjuk adatbázis szerkezetek felépítésében.
Majd meglátjuk! Ja, és bocs, nem neked szól a válasz nagy része. :)
Ha a naptárban a kivételes napokat is akarod jelölni akkor tényleg van ennek értelme, de ezt valamennyi munkával ebből is kigyűjtheted valamilyen szabály alapján. És ez még biztosabb is így automatikusan mint a kézi szerkesztőre bízni.
Adatmennyiségben és feldolgozásban ez rosszabb, de a többi adathoz ez képest elhanyagalhatóan kevés, nem hiszem, hogy érdemben számítana.
Például van egy alkalmazásod, menetrendeket gyárt. Amíg két forrásból dolgozol [calendar és calendar_dates] megteheted azt, hogy minden nap "általánosnak" tekinthető ami a calendar-ban vannak. Elmondhatom, hogy a 333-as busz hétfő, kedd, szerda, csütörötök, péntek, szombat megy, vasárnap nem megy; szeptembertől decemberig. DE van kivétel, amiknek a calendar_dates-ben a helyük, mondjuk szeptember 44.-én, ami vasárnap, hogy MÉGIS jár a busz, mert nyitva van aznap az ABC. Ekkor az alkalmazásom pirossal villogtatja a naptárban a szeptember 44.-i napot, hogy akkor kivételesen jár a 333-as, pedig nem szokott.
Ha csak a calendar_dates-ből veszem a dolgokat, akkor nem tudom megmondani, hogy az adott napi menetrendem általános, vagy kivételes.
Tehát a hátrányok, amik hirtelen eszembe jutnak: Ez információvesztés. -> Csak a calendar_dates-el kevesebb információt tudsz közölni, mint a calendar+calendar_dates-al. Több helyet is foglal. Lehet, hogy valahol a calendar jobban index-elt, mint önmagában csak a calendar_dates. -> Hatékonyságromlás.
A lényeg, hogy amit mondani szerettem volna: a két adatábrázolás nem ekvivalens. Legfeljebb addig, amíg Neked csak annyi információt hordoznak a calendar-ok, hogy valami mely nap közlekedik.
Lehetne ebből automatikusan generálni egy calendar.txt-t és egy kisebb calendar_dates.txt-t, de tartalmilag ugyanez lenne. Olvasgatni lehet, hogy szebb, de különben mindegy.
Csak azért mégsem "szabványos" (a szó nem szó szerinti értelmében).
Mert most hogy írtuk le a dolgokat? A GTFS egy "optional" részével (calendar_dates.txt), szemben egy "required" részével (calendar.txt).
Arról nem is beszélve, hogy a beiktatott napok ("exception_type" = 1) alkotják így a rendes menetrendet. Mit is jelent az, hogy "exception"?
Tehát lehet, hogy működik, de nem ésszerű. Előnyeit sem nagyon látom, a hátrányait annál inkább.
És innen már csak egy lépés és a GTFS adatbázisokat lehet naponta generálgatni, még véletlenül sem elmozdulni abba az irányba, hogy kiadok egy feed-et aminek a 90%-a tökéletesen lefed egy fél éves időintervallumot.
Tisztában vagyok, hogy vannak hirtelen változások, nem várom el, hogy a karácsonyi szünet már júliusban fel legyen vezetve, de azért legalább az eddigi színvonalat próbáljuk meg tartani.
[Ez az üzenet legkevésbé sem Neked szól :] Meg nem is biztos, hogy lustaság van a háttérben, de ha mégis, akkor szégyelljék magukat.
Vajon mi az oka, hogy ezt az utat választották? Olyan sok a kiiktatás augusztusban?
És ez már nem Neked, inkább a feeder-nek szól (nem tudom, hogy olvassák-e): ilyen esetben érdemes lenne az üres calendar.txt-t a feed-be pakolni, mert úgy a helyzet egyértelmű.
Nem tudja valaki, hogy hova lett a BKK által feed-elt GTFS adatbázisokból a 'calendar.txt' fájl? Már vagy egy hete hiányzik belőle. Egyelőre pótolom egy régebbivel, de.........
Ha van hozzá türelmed, akkor a következőket tudod tenni:
Vonalanként megnézed, hogy mit lehet referencia útvonalnak tekinteni - ebből van nagyjából 310 darab. Az ettől eltérőek valamilyen módon különlegesnek számítanak. Garázsmenet, hétvégén nem tér be az áruházhoz, vagy egyéb csonka.
Ez nem változik annyira sűrűn, hogy ne lehessen egyszer kézzel megcsinálni, viszont oda kell figyelni arra, hogy a GTFS-ben nem feltétlenül jó az ott lévő útvonal. Biztos észrevetted már te is, hogy az útvonalak nem feltétlenül zárulnak önmagukba. Ettől persze lehet, hogy a végállomások jók.
Például:
73-as troli Arany János utcai végállomásán a leszállóhely és felszállóhely között nincs felvéve útvonal. Hiszen a troli megérkezik a leszállóhelyhez, az utasok leszállnak és kvázi nem járatban áll át a felszállóhelyre.
Ugyanennek a vonalnak a másik végén, a Keleti pályaudvarnál – legalábbis látszólag – össze van húzva az útvonal két iránya. Ugyanabba a megállóba érkezik, mint ahonnan indul. Logikailag persze nincs kapcsolat az érkező megálló és induló megálló között, csak nem látszik a két irány útvonala között rés, mivel 0 kiterjedésű és amúgy is takarja a megállót jelző pötty.
És hogy világos legyen mire célzok, egy példa ennél nagyobb útvonalhiánnyal:
213-as busz, Baross Gábor-telepi hurok:
A Mátyás király utca (009447) az utolsó megálló a Kosztolányi Dezső tér felől a referencia útvonalon, mert itt kényszerből meg kellett törni az útvonalat (ezt nem részletezném). Az előző megállóból induló 213-as busz logikailag még a Mátyás király utcáig közlekedik, ott ki kell választani a XIII. utca / Dózsa György útig tartó járatot, ahol pedig a Kosztolányi Dezső térit. Korábban a Mátyás király utcánál bemondta a hangos, hogy végállomás és, hogy le kell szállni. Ezeket amennyire tudom sikerült javítani. Nem FUTÁR hiba és nem GTFS hiba. Az útvonalakat kell rendbe tenni, de vannak ilyenek is.
A lényeg röviden: Az az útvonal, amit az utazástervezőben látsz, a referencia útvonal. Elvileg ez lenne az adott viszonylatnak "Az útvonala". De vannak benne ilyen trükközések, úgyhogy érdemes átnézni, ha esetleg ezt a forrást használnád a csonkák szűrésére.
Azért kérdeztem, mert a menetrend alkalmazás egy ponttal jelzi a ,,rendhagyó útvonalat'', az adatbázisban viszont nem találtam semmit amiből kiderül az alkalmazás számára, hogy mi számít rendhagyónak.
Ha jól értelmezem a kérdést: sehogy. Korábban erről beszélgettünk is itt, hogy a GTFS-ből nem derül ki, mi egy adott járat "valódi" végállomása és útvonala, és mi számít csonkamenetnek, kocsiszíni vagy garázsmenetnek. Volt egy próbálkozás a bkk_ref nevű mezőkkel, ami az alap útvonalra tartalmazott adatot és máshol üres volt, de nem igazán vált be.
Elvileg minden hajnalban nézi a szerver, hogy van-e frissítés. Viszont mivel már csak egy létező link van, és időként lefrissül, így csak BPI topiktárs tudhatja a választ :)
Lehet, hogy kézzel frissíti és nem automatikusan tölti le és importálja az adatbázis. Ameddig én is így csináltam, nekem is voltak kimaradó exportjaim.
