Na, erről a táblázatról eszembe jut az elsőre általam kissé nehezen emészthető GTFS sajátosság: az indulási időpontok, azt hinné az ember, hogy 0 és 23:59 közé esnek. De nem! Így történhet, hogy a 6-os villamost 5:18-ra hoztad ki elsőnek, pedig hát ugye egész éjjel jár. A GTFS sajátosan nézi az éjszakákat, körülbelül úgy, mint a TV műsoros újságok: a szombat hajnali műsor még a pénteki oldalon van. A GTFS egész konkrétan a nappali hálózat kései indulásait 24 órán felüliként ábrázolja, így például az én videóm legmagasabb kezelési időpontja 29 óra 27 perc, ami a valóságban természetesen 5 óra 27 percnek felel meg reggel, de a GTFS így jelzi, hogy még egy előző napi szolgáltatásról van szó. Nálam ez mondjuk pont egy éjszakai járat, úgyhogy valószínűleg még most sem értem pontosan, mely szolgáltatások vannak ezzel a sajátos időfelfogással rögzítve.
Azt láttam, hogy egyes azonosítókba be van építve némi infó (pl. HCs - hétfőtől csütörtökig érvényes menetrend), de azért erre nem számítottam, hogy még a forgalmi szám is szerepel!
Úgy látom, a block_id tábla jobb szélén a forgalmi számok láthatók a _ jel után (legalábbis villamosviszonylatok esetén erősen gyanús). Készítettem egy új táblát, amivel összepárosítottam a block_id-t a forgalmi számmal. Ezt a következőképpen csináltam: egy lekérdezéssel összevontam (Group By) az összes block_id-t (7019 rekord), ezt kimásoltam Excelbe 2 egymás melletti oszlopba, és a másodikon Szövegből oszlopok -> tagolás _ jellel, amiből az első oszlop kuka. Az új táblában a block_id beállítható kulcsként.
Ezt az új táblát bekapcsoltam a lekérdezésbe a trips tábla block_id mezőjéhez. Ismerős számokat kaptam (pl. a 47-es villamos esetén 41-től 59-ig, a 18-asnál 1-től 10-ig plusz a két ilonás 21 és 22 számon). A 6-os nappali járatai 31-től 48-ig, az éjszakaiak 91-től 97-ig számozódnak.
Egy ilyen férőhely-kilométer adat valóban jó lenne, bár ez már nem az utastájékoztatás része, az adatbázisnak pedig ugyebár inkább ez utóbbi a célja.
Ha az Általad említett egyszerűsítéssel élünk, akkor azt könnyen megtehetjük egy új mező beillesztésével a Routes táblába. Sőt, bizonyos esetekben pontosabbak is lehetünk, a legtöbb járathoz beírhatjuk az ott közlekedő járművek pontos kapacitását. Kivétel pl. a 14-es villamos, ahol hétvégén csak két kocsi jár, de arra meg számíthatunk egy súlyozott átlagot az induló menetek számából. Ez mindössze 301 számadat bevitelét jelenti, szerintem meg is fogom csinálni legalább a metróra és a villamosokra. (A hévek esetében elég jelentős a hibaszázalék a dupla kapacitású nagyegységek miatt.)
A precízebb megoldás a Trips tábla kiegészítése lenne, de egy kicsit sok lenne a 157.501 rekordot karbantartani. :-)
A férőhelyhez hasonlóan be lehetne tenni egy alacsonypadlós férőhelyszámot is. Talán úgy a legcélszerűbb, hogy két külön mező legyen a magas- és alacsonypadlós férőhelyszám. Villamosoknál egyszerű, a vegyes buszjáratoknál átlaggal operálva, de pl. a Localo-s vonalakat is meg kellene bontani, mivel az a busz részben alacsonypadlós.
Azt pont nem, mert járműtípus nincs az adatbázisban. A sima km-t viszont ki lehet szedni, azt gondolom (nem egyszerű :p).
Ha mondjuk a programunkban deklaráljuk a szóló buszos vonalakat, valamint a villamost egységesen vesszük és a 1-4-6-ost két egységnek számítjuk, valamint tudjuk azt is, hogy mikor melyik HÉV-járat kisegység, melyik nagy, akkor egész jó közelítéssel lehet férőhelykm-t is számítani.
A Sindöc topikon érintettük még ezt a formátumot, annyit leírnék még így az elején, hogy a GTFS tulajdonképpen egy több szövegfájlos ZIP kötet. A szövegfájlokat ugyebár kitűnően lehet tömöríteni, a CSV formátum pedig a könnyű átalakítást teszi lehetővé. A GTFS, lévén Google "szabvány", leginkább az egyesült államokbeli formátumot követi, azaz a mezők egymástól vesszővel vannak elválasztva, a lebegőpontos számok tizedeselválasztója pedig a pont. A "rendes" szövegmezők idézőjelben vannak, így a bennük szereplő vesszők nem rontják a képet. Importálásnál erre kell vigyázni.
Mivel a topik alapvetően a BKV GTFS adathalmazára apellál, a másik buktatót csak érintem: a különböző adattáblák rendelkeznek opcionális oszlopokkal is, például nem kötelező megadni egy járatra jellemző leírást. Ezért szerepel mindegyik szövegfájl (adattábla) első sorában az oszlopazonosító is, így ugyanis olyan alkalmazás is készíthető, amely univerzálisan képes bármely elfogadott és ellenőrzött GTFS fájlt importálni. Ezzel a megoldással elkerülhetőek az üres oszlopok, mert amit nem használunk, egyszerűen bele sem rakjuk.
Ja és még egy nagyon fontos: UTF-8 a karakterkódolás, nem meglepő módon :)
Próbáld mindegyik mezőt szövegként importálni. A route text color mezővel lehet gond, mert számként próbálja importálni, de aztán jönnek a hexadecimális betűk. :-)
hungeri kérdése: "tudjátok-e melyik óra melyik percében van kint a legtöbb járat?"
Ha jól kérdeztem le, akkor nálam egy pénteki munkanapon egész percre kerekítve 7:09-kor indul a legtöbb járat, szám szerint 1104, a legkevesebb pedig 2:13-kor (41). De hogy mikor van kint a legtöbb, az már nekem túl bonyolult lekérdezés lenne.
Access 2003-ban a Szövegimportáló varázslóval indulj.
1. képernyő: Határolt, majd tovább
2. képernyő: Határoló a vessző legyen, Szövegjelölő az idézőjel, és "Az első sor tartalmazza a mezőneveket" legyen bepipálva.
3. képernyő: Egy új táblában, tovább
4. képernyő: Tovább
5. képernyő: Ne legyen elsődleges kulcs (lehetne, de nem létszükséglet)
És még mielőtt Befejezést nyomsz, menj be a Speciális képernyőre. Itt egyrészt a tizedesjelet állítsd át . (pont)-ra, és és állítsd mindegyik adattípust Szöveg-re a biztonság kedvéért. Így tuti nem lesz importálási hiba, de ha kell, később is átállítható a mezőtípus.
Most nincs előttem 2007-es Access, de ha azt használsz, megnézem, hogy ott mit kell másként csinálni.
A BKK közzétette a honlapján a BKV General Transit Feed Specification (GTFS) adatbázisát, amely gyakorlatilag a teljes BKV menetrendet és egyéb információkat tartalmazz. A topikban az adatbázis használatáról, a feldolgozás módjáról, az adatokban rejlő lekérdezési lehetőségekről és kimutatásokról fogunk beszélgetni.