Ha meglennének a járműtípusok is, akkor összefoghatnának a GTFS és BVE / MSTS szakértők és lemodellehzetnék Budapest egy napját, hasonlóan hungeri nagyszerű (a nyitó hozzászólásban linkelt) videójához, de pöttyök helyett már 3D járművekkel. :-)
Komolyra fordítva, tényleg tök jó ez a kerekesszékes kiegészítés. Lehet, hogy előbb-utóbb a Google útvonaltervezőjében ki lehet majd választani, hogy csak kerekesszékkel járható útvonalakat ajánljon?
Hát, már az alacsonypadlós kiadást sem igazán sikerül teljesíteni, a típusok talán még ennyire se stimmelnének. :/ Mondjuk arra jó lenne, hogy lássuk minek kéne mennie elvileg.
Egy érdekesség: az egyedüli olyan vonal, ahol néhány triphez az van jelölve, hogy nem tudható alacsonypadlós jármű van-e rajta, a 83-as. Ez persze logikus a vegyes és folyamatosan változó Solaris és busz kiadás miatt, de jó dolog, hogy ilyenre is gondoltak és terveztek vele.
Hm. Most átlapoztam a linkelt oldalt. Ezek szerint járműtípust is meg lehetne adni az adatbázisban. Már csak a BKK-t kéne rávenni, hogy tegyék is bele :D De már ez az alacsonypadlós jelölés is nagy előrelépés.
Nem végleges a módosítás, még nem fogadták el, pedig már jó ideje felmerült (lásd 1, 2, 3), ezért nincs még benne. Én már titkon reménykedtem benne egy ideje, hogy nálunk is használni fogják végre. :)
Első ránézésre az implementáció használhatóra sikerült, a trips táblában helyesen szerepelnek az értékek, de a stops tábla wheelchair_boarding értékei teljesen rosszak. Hiányzik pl. a nagykörúti megállók túlnyomó része, és a legtöbb megállónál 2-es érték szerepel (ami azt jelenti, hogy egyáltalán nem lehet ott kerekesszékkel felszállni) -- ehelyett 0 kéne, hogy szerepeljen.
Elméleti javaslatom a következő: csinálj ebből a sokszoros lekérdezésből egy olyan lekérdezést, amibe csak az 1st_dep oszlopot teszed be, összesíted a szumma gombbal és Min-t állítasz be a Group By helyett. Ez elvileg egyetlen cellát fog eredményül adni, ami mutatja a legkisebb időt, jelen esetben 04:41. Ha most egy újabb lekérdezést csinálsz, amibe beteszed az eredetit és ezt az egy cellást, és az eredeti lekérdezés 1st_dep mezőjét összekötöd a másik lekérdezés egyetlen mezőjével, akkor elvileg leszűrted arra az egy sorra.
Ugyanezt lehet eljátszani a last_arr mezővel, értelemszerűen Max beállítással. Végül ezt a 2 x 1 soros lekérdezést vond össze egy újabb lekérdezésben.
Van több sorom, aminek biznyos cellái soronként egyeznek. Hozok egy példát, úgy könnyebb elmagyarázni szerintem nekem is :D
route serv_id forg 1st_dep dep_stop last_arr arr_stop tavolsag 0050 A84870AVVSR 4 04:41:00 Ferenciek tere M 05:16:00 Rákospalota, Kossuth utca 12294 0050 A84870AVVSR 4 05:26:00 Rákospalota, Kossuth utca 20:18:00 Pasaréti tér 130368 0050 A84870AVVSR 4 06:19:00 Pasaréti tér 19:17:00 Rákospalota, Kossuth utca 112938
Ezekből szeretnék egy olyat, hogy a 1st_dep és dep_stop oszlopból a legkisebb idő, és hozzá tartozó hely; a last_arr és arr_stop oszlopból a legnagyobb idő, és hozzá tartozó hely maradjon meg; a tavolsag oszlopban lévő számok pedig összeadódjanak. Lehetőleg minél egyszerűbben, hogy én is megértsem :D
Ja, és ez a táblázat már egy lekérdezés lekérdezésének a lekérdezésének az eredménye :D
Ebben találsz egy kész lekérdezést is, ezt alapszintű Access ismeretekkel módosíthatod. További információk a topik első 253 hozzászólásában, de azért kérdezhetsz. :-)
Üdv emberek egy kis segítséget szeretnék kérni.Nem igazán értek hozzá,szóval lehet,hogy néhány kérdés hülyén fog hangzani.Szintén közlekedésmániás vagyok de eddig még nem annyira foglalkoztam a GTFS bázissal.A következő a probléma:megvannak a txt fájlok.Mit kell velük csinálni?
Hasonló problémával én is találkoztam. A 61-es villamosnál pl. ha a mai napra nézek menetrendet, két intervallumot is kapok: 04.20-tól 06.14-ig, és 04.21-től 07.31-ig, tehát van benne egy duplán lefedett időszak, 04.21-től 06.14-ig. Viszont ha a calendar_dates táblát is belekombinálom, akkor kijön, hogy erre az időszakra a második intervallumra 2-es típusú kivétel van beállítva szinte az összes napra, így csak az első intervallumos menetrend érvényes.
Tehát: 04.20-tól 06.14-ig alapmenetrend van, de a kiiktatásos menetrendet nem csak 06.15-től 07.31-ig rögzítették, hanem már 04.21-től, és kivételt állítottak be azokra a napokra, amikor az (a kiiktatásos menetrend) nincs érvényben, vagyis 06.14-ig.
Egy olyan kérdésem lenne, hogy hogy lehet megjeleníteni az olyan gtfs adatokat, amik pl. itt http://data.flaktack.net/ , ezen a helyen vannak? Meg tudnak ezek jelenni a Googla Mapsban, vagy valami más alkalmazás kell hozzájuk?
Nem tudom, ki mikor melyik verziót töltötte le a BKK honlapjáról, de a mai napon elérhető és általam most letöltött (április 20-i dátumú) verzió július 31-ig tartalmazza a menetrendeket. A struktúrában úgy tűnik, nincs változás, legalábbis a táblák importálását követően hibátlanul működnek a lekérdezéseim.
Mivel a táblák importálási specifikációját már korábban elmentettem, az importálás 1-2 perc alatt elkészült. Az adatok felülírását követően célszerű összerázni az adatokat az Adatbázis tömörítése és helyreállítása funkcióval, mert egyébként a felülírt táblák is foglalják a helyet.
A kérdésedre engedelmeddel itt próbálkoznék a válaszadással, mivel másokat is érdekelhet.
A kérdés arra vonatkozik, miként lehet a GTFS-ből a rendkívüli menetrendeket lehívni egy adott napra, pl. a tegnapi szombati napra, ami munkanap volt, vagy mondjuk március 15-re, ami keddre esett, de munkaszüneti nap volt.
A megoldás kulcsa a calendar_dates tábla, ahol a service_id és a dátum alapján kétféle exception_type látható. Ezek jelentése:
1: olyan menet, ami aznap közlekedik, de máskor nincs a menetrendben
2: olyan menet, ami aznap nem jár, pedig alapesetben járna
A calendar_dates táblát a service_id mezővel kell a trips táblához kötni, és így lehet dátumra és exception_type-ra szűrni.
Úgy tapasztaltam, hogy azokra a menetekre, amelyek az eredeti és a kivételes menetrendben is benne vannak, általában két rekordot találunk a calendar_dates táblában, 1-essel és 2-essel is. Ennek az az előnye, hogy elég 1-esre szűrni, és megkapjuk az adott napi menetrendet, mivel az tartalmazza a szokásos és a rendkívüli meneteket is. (Húsvét környékén valamiért más volt a helyzet, nem voltak 1-es bejegyzések, de azon már túl vagyunk.)
A funkcionalitásból én sem engedek, pont az a lényege ennek. Nekem 50MB-os adatbázisom van jelenleg, 7MB zippelve, a kicsomagolása telefonon 9-10 másodpercet vesz igénybe, utána viszont már instant indul a program.
Szóval ha egy pofás interfészt csinálsz, jól működik a program, akkor szerintem felesleges 400KB-ba sűríteni mindent és a funkcionalitást kidobni a kukába.
