Hivatalos FUTÁR API lesz valamikor vajon a GTFS-hez hasonlóan?
Szóval nem valami teszt url, ami éppen működik vagy nem, hanem egy stabil url, satbil api-val, amit lehet használni.
Bár ahhoz ugye állandó erőforrás kell, ezért kérdés, hogy az is ingyen használható lenne-e. A GTFS-hez csak fel kell tölteni egy file-t, de a FUTÁR apihoz olyan szerverek kellenének, amik bírják a terhelést.
Tapasztalataim szerint a hivatalos futár app is küszködik néha az adatok letöltésével, vagyis a backend nincs csúcsformában.
Elvileg pazarlóbb, de a többi adat mennyiségéhez a naptár rész elhanyagolható. Ugyanígy pazarló, hogy 1193 féle van, de tartalmilag csak 133 különbözik, a többi ismétlés. Automatizáltan át lehet ezt alakítani, ugyanígy a helyesebb megoldás is kijön calendar.txt-vel, ha kell ez valamiért.
Ha minden igaz most úgy működik a dolog, hogy x és y dátum között vagy az van felsorolva, hogy mikor jár, vagy az, hogy mikor nem, attól függően, hogy melyikből van kevesebb.
Eddig volt egy tábla, amiben minden menetrend* fel volt sorolva egy oszlopban és mellett ott voltak a napok hétfőtől vasárnapig. Ha jár, akkor az adott nap, akkor bele van vésve egy 1-es.
A mostani megoldás talán takarékosabb és mintha a GTFS szempontjából így helyesebb lenne, szóval nem vennék rá mérget, hogy valaki javítani fogja.
Nem túl egyértelmű, amit írsz, de azt hiszem arra gondolsz, hogy a dátum helyén 0000-00-00 van. Ez azért van, mert jelenleg egyik járat sem közlekedik soha, kivéve bizonyos napokon. Hiányzik a calendar.txt, ha jól vettem ki az eddigi beszélgetéseket, de majd kijavít valaki, ha nem így van :)
Például a 33-as soha nem jár, kivéve hétfőtől péntekig, szombaton és vasárnap. Azaz minden egyes nap kivétel a szabály alól.
Még a garázsmeneti útvonalakhoz egy kis finomság. :)
Múlt héten Máté betette a budapesti buszos topikba, hogy nem lett javítva a 241A garázsmeneti útvonala, ezért megtévesztő utazástervek jöhetnek ki. Én most betennék egy durvább példát:
Vajon mit szólnának odabent, ha valaki bekopogtatna a Metró DBR járműtelep (kapu)megállóhelynél, hogy ő szeretne felszállni a metróra, mert ezt az útvonalat tervezte neki az utazástervező? :D :D
É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. :)
