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.
Az biztos, hogy a végén rányomtak pl. egy zipet, de előtte is elég komoly tömörítést kellet, hogy alkalmazzanak, akár "kézzel" (nem beépített eszközök segítségével).
De ha már a stops táblánál járunk, akkor érdemes megjegyezni, hogy ők az azonos nevű megállókat mind összevonták, ami viszont néhol gondokhoz vezet.
Mindenesetre én egy 5 MB alatti tömörített és 20 MB alatti tömörítetlen adatbázissal elégedett lennék, ami szerintem elérhető csak a menetidők letárolásával. A további optimalizáció (legalábbis nekem) aránytalanul sok munkát igényelne (ugyanúgy az adatok tömörítése, mint a tömörített adatokkal való későbbi dolgozás), a funkcionalitásból meg nem akarok engedni.
De egyszerűen nem értem, hogy hogy lehet 360KB az egész adatbázis. Egy Varchar az a hosszának megfelelően L + 1 byte helyet foglal, ahol L a karakterlánc hossza. A Stops táblában ahol a megállók adatai vannak 5573 rekord van nálam jelenleg. Ha átlagban mondjuk 15 karakterrel számolunk megállónévnél, akkor 89 168 byte helyet foglal, így már ezzel el is megy a negyede szóval nem tudom hogy oldották meg. Lehet valamilyen módon tömörítve van az adatbázis, sőt biztos :)
De a "visszafejtett" kódban is találni ilyesmiket hogy GZIPInputStream, úgyhogy valamilyen tömörítés ott tuti van.
A calendarnál a rekordok számának csökkentésével lehet a legtöbbet nyerni, nekem a friss adatbázisban 74 rekord lett az eredmény, pedig még így is vannak duplikátumok.
Egyébként, hogy kis kontextust adjak, nekem a 67 MB-os adatbázisból 57 MB a stop_times és 9 MB a trips. Ha a stop_times-tól meg lehetne szabadulni (mondjuk csak a menetidők tárolásával), az jó eredmény lenne. :)
Meg egy kis statisztika: összesen 145 megállóban különbözik az érkezési és indulási időpont.
A mobilos alkalmazásfejlesztéshez érdemben nem tudok hozzászólni, de van egy-két lehetőség, amivel csökkenteni lehet az adatbázis méretét. Nem fogok sok újdonságot mondani, inkább csak összefoglalok néhány dolgot.
Stop_times tábla: néhány kivételtől eltekintve az arrival_time és a departure_time azonos, az érkezési idő kidobható. Ezenkívül a stop_sequence is redundáns olyan értelemben, hogy a trip_id-n belül időben rendezve megvan a megállók sorrendje, feltéve, hogy egyik járat sem megy vissza az időben. :-) A shape_dist_traveled meg az alkalmazás jellegétől függően lehet, hogy fölösleges.
A többi táblában elérhető helymegtakarítás ehhez képest elenyésző méretű, de azért összefoglalom azokat is.
Calendar: 1250 rekordból 1242 esetben (az általam letöltött, nem a legfrissebb verzióban) hétfőtől-csütörtökig azonosak a bejegyzések, tehát egyforma a menetrend, elég lehet egy mező (ezzel spóroltunk 157 byte-ot :-) )
Routes: a route_desc szövegmezőnek nincs valós adattartalma, csak kiegészítő információ, a végállomások a menetrendből is kikövetkeztethetők.
Trips: a trip_headsign szövegmező redundáns, erről is tegnap beszélgettünk.
Egyelőre androidra tervezem először az alkalmazást, de még az androidos telefonomat sem vettem meg... Az app előtt viszont csinálok prototípust.
A 70 MB az azonosítók intekre konvertálásával sikerült, de mobilra ez a méret még mindig sok lesz. A menetidő alapú tömörítés viszont nem rossz ötlet, azzal további jelentős méretcsökkenést lehet elérni. SQLite-ra konvertálással viszont szerintem nőni fog a méret a változó mezőhosszak miatt (bár igazából a keresés gyorsasága miatt aggódom, még soha nem használtam SQLite-ot).
Az androidos GTFS appról most olvastam, hogy maga a program 40 kB, és eredetileg a teljes csomag 400 kB volt, tehát a kettő különbözete az adatbázis. Ez elég szép teljesítmény.
A GTFS szerintem jó, csak nem az a célja, amit mi csinálunk vele. Útvonaltervezésre van kitalálva, és arra jól működik. Meg persze ez egy köztes, szabványos(!) formátum, ezúton válik lehetővé, hogy egyáltalán valahogy eljussanak hozzánk a menetrendi infók. A legjobban én azt hiányolom belőle, hogy nincsenek feltüntetve az alacsonypadlós járatok, pedig erre már létezik egy nagyjából elfogadott szabvány kiegészítés.
Az érdekes az lesz egyébként, amikor majd a real time adatok elérhetővé válnak.
MySQL-ben 70MB-nál úgy tartasz hogy módosítottál rajta gondolom. Ha SQLite-ra átdobot az adatbázist, még többet fogsz tudni faragni a méretén. Az Androidos alkalmazást (már ha egyről beszélünk) néztem én is és csodálkozok hogy 500KB az egész app mérete. Csak emulátoron néztem mivel ilyen készülékem nincs, memóriából 20Mb-ot eszik, szóval valamilyen módon tuti hogy tömörítve van az adatbázis.
Milyen platformra tervezed az alkalmazás kiadását? Mert én például a Windows Phone 7-es platformban gondolkozok, az alkalmazás maga már teljesen kész, még az adatbázison dolgozok.
A GTFS-ről viszont az a véleményem hogy több vele a nyűg mint amennyi hasznot hoz. Bármerre nézek, mindenhol csak arról olvasni, hogy "én így módosítottam az egészet hogy használható legyen". De legalább így a BKK-tól is kapunk hivatalos adatbázist amivel dolgozhatunk.
