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.
Arra a GTFS-RT-re gondolok, amit a BPI-779 féle oldal dolgoz fel (ott azt írja, hogy a GTFS-RT adatbázis kerül feldolgozásra, ellenben jó, ha hetente frissül).
Azt igencsak kétlem, mert a GTFS-RT 5 másodpercenként frissül. Amiről te beszélsz, az valószínűleg a sima budapesti GTFS "új" és ma már egyedüli kiadása. Ennek naponta jön ki új változata, és most azt hiszem tényleg nem volt 3 napig, de előtte elég sűrűn jött, és ugye még a 3 nap is sokkal gyakoribb, mint a régi 7. Persze bárcsak ne lenne szükség napi frissítésre.
Nagyjából ismerem a feltételeket, és szerintem nem ennyire egyértelmű a helyzet. Erre a konkrét felhasználási módra inkább a 3c és 3d pontok vonatkoznak, de itt sem tiszta, hogy pontosan mi a teendő. Úgy gondolom, hogy ebben az esetben nem is érdemes ezzel foglalkozni. Nem az az ODbL (és más, hasonló liszenszek, pl. GPL) célja, hogy átláthatatlan és költséges jogi problémák elé állítsa az embereket, hanem hogy megakadályozza, hogy valaki benyúlja és elzárja a közösség által teremtett értékeket.
Itt az adatok 99%-a a publikus GTFS-ből származik, a maradék 1% pedig az OSM-ről. Mindkét forrás fel van tüntetve az alkalmazásban, így aki akarja, könnyedén megtalálja az eredeti adatokat. A kész adatbázis is letölthető, de csatlakozom nunavummiuq-hoz, semmi értelme.
Privát célra használhatod az openstreetmap-et, de ha pl. nyilvános kommersz szoftvert csinálsz, és az adatbázisodban felhasználsz OSM adatokat, akkor az derivatív adatbázisnak minősül, és ezt az adatbázist ingyen letölethővé kell tenned:
if you make a database which includes OSM data and any additional information (including using information to decide on OSM features NOT to include in your database), then this would be classed as a "derivative database" and should be made available under the Open Database License as in 3b above.
Amúgy ha térképalap, akkor a Google-t ajánlom. Mivel azt nézik a legtöbben, így a hiányzó utcaneveket is nekik jelentik a legtöbben, ebből következőleg az ővék a legkevésbé pontatlan és legkevésbé hiányos.
Érdemes összehasonlítani pl. a Budakeszi Tesco környékén a térképalapokat. Ott pl. az én közbenjárásomra lettek pótolva a hiányzó utcanevek.
A kerület és a közterület neve az OpenStreetMap-ről származik, az irányt pedig a megállón áthaladó járatokból próbálja kitalálni (általában a következő megálló neve egyszerűsítve).
A járatoknál levő megjegyzés a routes.txt route_long_name mezőjéből jön, kisebb módosításokkal (pl.: "-os hév (Tököl)" => "Tököli hév"). A *pótló megjegyzés a route_id első két betűje alapján kerül hozzáadásra. Ezek be vannak égetve a GTFS feldolgozóba, ha valami változik, kézzel átírjuk.
Mindkét dolog csak erre az alkalmazásra jellemző, más appok ezt másképp kezelhetik, vagy teljesen más koncepciókkal dolgozhatnak.
