Szenzoradat alapú okostelefonos közösségi közlekedési információs rendszer Szerző:
Hunyady Márton Mérnökinformatikus MSc
Témavezető:
Dr. Lukács Gergely egyetemi docens, PPKE-ITK
Pázmány Péter Katolikus Egyetem Információs Technológiai és Bionikai Kar
Budapest, 2015.
Pázmány Péter Katolikus Egyetem Információs Technológiai és Bionikai Kar Diplomaterv témabejelentő nyilatkozat Hallgató Név: Hunyady Márton
Neptun kód: ACNBHD
Szak: Mérnökinformatikus MSc (IMNI-MI)
Témavezető Név: Dr. Lukács Gergely Beosztás, tudományos fokozat: egyetemi docens, PhD
Dolgozat A dolgozat címe (magyarul): Szenzoradat alapú okostelefonos közösségi közlekedési információs rendszer A dolgozat címe (angolul): Information service for public transportation based on smartphone sensor data A dolgozat témája Mind a városi, mind pedig a városok közötti közösségi közlekedésben egyre elterjedtebbé válik, hogy a járműveket felszereljék pontos helyadatokat szolgáltató rendszerekkel. Emellett az utasok nagy része is magával hordja az okostelefonját, amelyek a bennük található helymeghatározó rendszer és a különféle szenzorok segítségével szintén alkalmasak a pozíció pontos meghatározására. Ezen adatokat felhasználva lehetőség nyílik olyan szolgáltatásokat biztosítani, amelyek korábban nem voltak megvalósíthatóak: segítségükkel valós idejű, a felhasználó számára személyre szabott útvonaltervezést és navigációt lehet nyújtani, figyelembe véve az aktuális forgalmi viszonyokat. Emellett a tömegközlekedési vállalat is pontosabb információkkal rendelkezhet az általa üzemeltetett járművek kihasználtságáról, az utasok által használt átszállásokról és útvonalakról, melyek ismeretében jobb szolgáltatást tud nyújtani. Ennek megvalósításához szükség van arra, hogy pontosan meg lehessen határozni, hogy melyik utas melyik járművön utazik, vagy hol gyalogol, illetve várakozik az átszállásra. A dolgozat egy olyan rendszer megvalósításának lehetőségeit, felépítését, működését és bizonyos funkcióinak megvalósítását mutatja be, mely a járművek és az utasok által nyújtott adatokat összevetve képes a fenti szolgáltatások biztosítására.
2
A hallgató feladatai Tekintse át a közösségi közlekedést támogató, elsősorban mobil, okostelefonos alkalmazásokat! Tekintse át az okostelefonos aktivitásfelismerés lehetőségeit a szakirodalom és az elérhető rendszerek alapján! Tervezzen meg és készítsen egy olyan szoftverrendszert, melynek segítségével meghatározható egy okostelefonnal rendelkező felhasználó aktivitása, illetve az, hogy melyik járművön utazik! Tervezzen meg egy olyan okostelefonos, közösségi közlekedési alkalmazást, mely a felhasználó valós pozícióját, aktuális járművét felhasználva személyre szabott utazási információkat szolgáltat! Valósítsa meg a rendszer kiválasztott moduljait!
A témavezetést vállalom.
A témavezető aláírása
Kérem a diplomaterv témájának jóváhagyását. Budapest, .......................................
A hallgató aláírása
A diplomaterv témáját az Információs Technológiai és Bionikai Kar jóváhagyta. Budapest, .......................................
Dr. Szolgay Péter dékán
A hallgató a konzultációkon részt vett és a kiírásban foglalt feladatokat teljesítette. A dolgozat a TVSZ 3. sz. mellékletében foglalt tartalmi és formai követelményeknek megfelel. Budapest, .......................................
A témavezető aláírása
3
Alulírott Hunyady Márton, a Pázmány Péter Katolikus Egyetem Információs Technológiai és Bionikai Karának hallgatója kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, és a diplomatervben csak a megadott forrásokat használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen a forrás megadásával megjelöltem. Ezt a diplomatervet más szakon még nem nyújtottam be. Budapest, 2015. december 14.
.................................................... Hunyady Márton
4
Tartalom Tartalmi összefoglaló ................................................................................................................... 7 Abstract ........................................................................................................................................ 8 1. Bevezetés és motiváció ........................................................................................................ 9 2. Közösségi közlekedési rendszerek ..................................................................................... 11 2.1. Forgalomirányító és utastájékoztató rendszerek ......................................................... 11 2.1.1. Budapest forgalomirányítási és utastájékoztatási rendszere ................................ 11 2.1.2. A Kisalföld Volán forgalomirányítási és utastájékoztatási rendszere ................. 12 2.1.3. A MÁV forgalomirányítási és utastájékoztató rendszere .................................... 13 2.2. Utazástervező rendszerek ........................................................................................... 14 2.2.1. Google Maps ...................................................................................................... 14 2.2.2. A BKK saját útvonaltervező szolgáltatása .......................................................... 14 2.2.3. Mobilalkalmazások utazástervezéshez ............................................................... 16 2.2.4. Közösségi útvonaltervezés és közlekedésszervezés ............................................ 18 2.3. Közösségi közlekedési adatok .................................................................................... 18 2.3.1. Alapfogalmak ..................................................................................................... 19 2.3.2. Adatforrások Budapesten ................................................................................... 19 2.3.3. A budapesti közlekedési adatok tartalma ............................................................ 21 3. Kísérleti mérésadatgyűjtő rendszer .................................................................................... 24 3.1. A mérésadatgyűjtő rendszer architektúrája és implementációja ................................. 24 3.2. Adatgyűjtő szoftver .................................................................................................... 25 3.2.1. Az adatgyűjtés ütemezése ................................................................................... 25 3.2.2. A tevékenység rögzítése és az adatok feltöltése .................................................. 26 3.2.3. Adatvédelem ....................................................................................................... 27 3.2.4. Adatgyűjtők motiválása ...................................................................................... 27 3.2.5. Időszinkronizáció ............................................................................................... 28 3.2.6. További gyűjthető adatok ................................................................................... 28 3.2.7. Tapasztalt problémák .......................................................................................... 28 3.3. Gyűjtött adatok ........................................................................................................... 29 3.3.1. Földrajzi adatok .................................................................................................. 29 3.3.2. Gyorsulásmérő és más szenzorok ....................................................................... 32 3.3.3. Tömegközlekedési adatok .................................................................................. 32 3.4. Referencia eredmények előállítása ............................................................................. 33 3.4.1. Utazáslista előállítása ......................................................................................... 33 3.4.2. Annotáló felület .................................................................................................. 33 4. Az adatok elemzése ............................................................................................................ 37 4.1. Földrajzi adatok feldolgozása ..................................................................................... 37 4.1.1. A földrajzi adatok tárolása .................................................................................. 37 4.1.2. 4.1.3. 4.1.4.
Az élő járműadatok és a készülék helyadatainak egyeztetése ............................. 38 Valós idejű működés .......................................................................................... 44 A módszer paraméterezése és teljesítőképessége ................................................ 44
5
4.1.5. Továbbfejlesztési lehetőségek ............................................................................ 45 4.2. Szenzoradatok elemzése ............................................................................................. 46 4.2.1. 4.2.2. 4.2.3. 4.2.4.
Korábbi munkák ................................................................................................. 46 Adatok kiválogatása és címkézése ...................................................................... 47 Adatok előkészítése ............................................................................................ 47 Feature kinyerés ................................................................................................. 48
4.2.5. Tanulás és az eredmények kiértékelése .............................................................. 51 4.2.6. Gyorsítási lehetőségek ........................................................................................ 53 4.2.7. Végrehajtás a készüléken .................................................................................... 53 4.3. Földrajzi és szenzoros adatok együttes alkalmazása ................................................... 53 4.4. Az elemzés menete egy példán bemutatva ................................................................. 54 5.
Információs rendszer .......................................................................................................... 58 5.1. Felhasználási esetek ................................................................................................... 58 5.1.1. Utasok számára nyújtott információk ................................................................. 58 5.1.2. Közlekedési vállalatok számára nyújtott információk ........................................ 60 5.1.3. A funkciók megvalósításához szükséges adatok ................................................. 61 5.1.4. Működési feltételek ............................................................................................ 62 5.2. Prototípus rendszer ..................................................................................................... 64 5.2.1. Rendszer architektúrája ...................................................................................... 64 5.2.2. Megvalósult funkciók ......................................................................................... 66 5.2.3. API leírás ............................................................................................................ 68 5.2.4. Mobilalkalmazás ................................................................................................ 69 5.2.5. Szerveroldali adattárolás és -feldolgozás ............................................................ 72 5.2.6. Tervek a következő funkciókra........................................................................... 73 5.3. Skálázódó, éles működésre alkalmas rendszer............................................................ 80 5.3.1. 5.3.2. 5.3.3. 5.3.4.
Követelmények ................................................................................................... 80 Felhőszolgáltatások ............................................................................................ 81 Szerveroldali optimalizálás ................................................................................. 82 Mobilalkalmazás változásai ................................................................................ 83
5.4. További lehetőségek ................................................................................................... 83 5.4.1. Beaconök ............................................................................................................ 83 5.4.2. Futár API-ban hasznos változtatások .................................................................. 84 5.4.3. Gyakoribb járműhelyadatok ............................................................................... 84 5.4.4. Egységes API több szolgáltatónak ...................................................................... 84 6. Összefoglalás ..................................................................................................................... 85 Köszönetnyilvánítás ................................................................................................................... 86 Irodalomjegyzék ........................................................................................................................ 87
6
Tartalmi összefoglaló Ma sok szempontból más a helyzet a közösségi közlekedési információkkal kapcsolatban, mint akár csak 5 évvel ezelőtt. Jelenleg a nagyvárosokban, de szépen lassan a városok közötti közlekedésben is élőben közlik a járművek a pozíciójukat az interneten, és a megállókban kijelzők mutatják, hogy melyik járat mikorra várható. Sokat változott az is az elmúlt években, hogy az utasok milyen információkhoz férhetnek hozzá. 2010 óta 5%-ról 40% fölé nőtt Magyarországon az okostelefont használók aránya. Ezek a készülékek szinte mind rendelkeznek beépített helymeghatározó képességgel, illetve többféle szenzor (pl. gyorsulásmérő, giroszkóp) is megtalálható bennük. A közlekedési vállalatok és az utasok adatainak együttes felhasználásával lehetőség nyílik olyan szolgáltatások és információk biztosítására, ami korábban lehetetlen volt: a felhasználók számára például személyre szabott útvonaltervezést és valós idejű navigációt lehet nyújtani okostelefonjukon, míg a közlekedési vállalat sokkal pontosabb információkat kaphat arról, hogy utasai mikor merre közlekednek – ezeket korábban csak hosszas és nehézkes mérések segítségével lehetett megbecsülni. Jelen diplomaterv azzal foglalkozik, hogy hogyan lehet a felhasználók okostelefonjainak hely- és szenzoradatait összegyűjteni, majd pedig ezeket a járművek által biztosított helyadatokkal összevetve miként lehet pontosabb és személyre szabott információkat biztosítani mind az utasoknak, mind pedig a közlekedési vállalatoknak. Ezek előállításához a dolgozat bemutat egy módszert, ami képes arra, hogy valós időben meghatározza a járatinformációk és az okostelefon által nyújtott helyadatok segítségével azt, hogy az utas melyik járművön utazik. Emellett az eredmények pontosítása érdekében a telefon szenzoradatainak
segítségével
tevékenységfelismerést
is
végrehajt.
A
két
módszer
összekapcsolásával a járat meghatározása pontosítható, valamint a járművekre történő fel- és leszállás, illetve a megállóba érkezés időpontja megmondható. Ennek segítségével az átszállásra szánt idők pontosabban becsülhetők. A módszer kialakításához először egy kísérleti mérésadatgyűjtő rendszer implementálására volt szükség, ami egy mobilalkalmazásból és egy hozzá kapcsolódó szerverből áll. Ennek segítségével valós utazások adatai lettek összegyűjtve, amiket elemezve ki lehetett alakítani a jármű-, valamint a tevékenységfelismerő algoritmust. Az itt szerzett tapasztalatok alapján létrejött egy okostelefonos
prototípus
információs
rendszer,
amin
a
különféle
funkciók
kis
felhasználószámmal kipróbálhatók, tesztelhetők. Végül a dolgozat bemutatja, hogy mire van szükség ahhoz, hogy ez a rendszer több felhasználót is ki tudjon szolgálni, és így egy széles kör által használható, éles mobil információs szolgáltatást lehessen létrehozni. 7
Abstract Today a lot of information in public transportation differ from the ones 5 years ago. Currently not only in big cities, but slowly also in the long distance transportation vehicles are publishing their positions live to the internet, and displays in the stops are showing when the next vehicle will arrive. In the past years also many things changed about what information people can access. Since 2010, users of smartphones increased from 5% to above 40% in Hungary. Almost all of these devices have built-in localization capabilities and multiple sensors (e.g. accelerometer or gyroscope). With the combined use of the data of public transit companies and the passengers, it becomes possible to provide services and information which were previously impossible: users can have personalized route planning and real-time navigation on their smartphones, while the transit companies can have more precise information about when and where their passengers travelled. Without these data this could be achieved only with long and expensive measurements. This thesis is about how it is possible to collect location and sensor data from the users, and use these combined with the location data of the vehicles to provide better and personalized information both to the passengers and the transit companies. To do this, the paper describes a method which is capable of determining which vehicle the passenger is currently travelling on, using the vehicle information and the location data of the smartphone. To make these results more accurate, it performs an activity recognition using the sensors of the smartphone. With the fusion of these two methods, the currently used vehicle can be determined precisely, and also the exact time of getting off a vehicle or arriving to a stop can be calculated. Knowing these, the duration of the transfers can be estimated better. To create this method, it was necessary to implement an experimental data collection system, which consists of a mobile application and a server which stores the data. With these, real travel data was collected, which have been analyzed and used to create the vehicle and activity detection algorithms. Based on these experiences, a smartphone information system prototype could be created, which is suitable for experimenting and testing the different functions with a few users. Finally, the thesis describes what is necessary in order to make this system serve more users, and how it is possible to create a scalable, production mobile information system.
8
1. Bevezetés és motiváció A közlekedési járműadatok elérhetőségének, az okostelefonok elterjedésének, valamint a bennük található szenzoroknak és helymeghatározó szolgáltatásnak köszönhetően lehetőség nyílik a közösségi közlekedéssel kapcsolatban olyan információk összegyűjtésére, amelyek korábban reálisan nem voltak kivitelezhetők. A mobil hely- és szenzoradatok segítségével a felhasználók mozgása és viselkedése nem csak abszolút módon, hanem a járművekhez képest is meghatározható, így információt lehet gyűjteni mind az egyén mozgásáról és viselkedéséről, mind pedig a tömegközlekedés általános működéséről. Ezen adatok felhasználásával lehetőség nyílik arra, hogy jobb minőségű, személyre szabott útvonaltervező és navigációs szolgáltatást biztosítsunk, mint amit a jelenlegi rendszerek képesek nyújtani. Emellett az így kinyert adatok a közösségi közlekedés hatékonyságának javításához is hozzájárulhatnak, valamint további területeken is felhasználhatók. A dolgozat célja, hogy a meglévő megoldások és rendszerek ismertetése után egy olyan információs rendszert hozzon létre, ami ezeket a feladatokat hatékonyan meg tudja oldani. Ehhez elsőként egy olyan kísérleti mérésadatgyűjtő rendszer elkészítésére van szükség, melynek segítségével a járművekre és személyekre vonatkozó hely- és szenzoradatokat nagy mennyiségben lehet gyűjteni, majd pedig egy megfelelő adatbázisban tárolni lehet ezeket. Amennyiben ezek rendelkezésünkre állnak, el lehet kezdeni az adatokat elemezni. Első körben külön a hely-, illetve a szenzoradatokat, majd pedig meg kell nézni, hogy hogyan lehet ezt a két módszert összekapcsolni, és ezáltal egy hatékony és pontos járat- és tevékenységmeghatározást biztosítani, aminek segítségével az információs rendszer szolgáltatásai megvalósíthatóak. Az adatelemzések tapasztalatai ismeretében fontos specifikálni, hogy milyen feladatokat akarunk megoldani az információs rendszerben ezen algoritmusok segítségével. Ezek egyrészt lehetnek az utast segítő szolgáltatások (például átszállási lehetőségek megjelenítése, valós idejű, személyre szabott navigáció, átszállási idők pontosabb becslése), másrészt a rendszer által előállított adatok alkalmasak arra is, hogy a közlekedési szolgáltatónak visszajelzést, statisztikákat tudjon adni a felhasználók mozgásáról, ezáltal segítve a tömegközlekedésnek az utasok számára legjobb irányban történő fejlődését. Ezen specifikáció ismeretében két rendszert érdemes megtervezni, illetve a későbbiekben létrehozni: egy könnyen módosítható, bővíthető prototípus rendszert, ami, bár sok felhasználót nem támogat, de az algoritmusok kiértékelésére és kis létszámú tesztelésére alkalmas. Ezután pedig szükséges megnézni, hogy mit kell tennünk annak érdekében, hogy ezek az algoritmusok jóval nagyobb felhasználói kör számára is elérhetők legyenek egy skálázódó, éles rendszer létrehozásával.
9
1. ábra: A dolgozat felépítése. A dolgozat a létező megoldások ismertetése után bemutatja a piros színnel ábrázolt saját munkát az ábrán látható fejezetfelosztás alapján. A dolgozat a 2. fejezetben áttekintést nyújt a meglévő megoldásokról: a jelenlegi tömegközlekedési rendszerekről, az azokat támogató alkalmazásokról és az általuk használt adatformátumokról. Ezután a 3. fejezetben ismerteti a kísérleti mérésadatgyűjtő rendszert: az ennek részeként elkészült adatgyűjtő mobilalkalmazással (3.2. alfejezet) nyílt lehetőség egy nagyobb adatmennyiséget összegyűjteni, amin a későbbiekben el lehetett végezni a különféle elemzéseket. A 3.3. alfejezet emellett ismerteti a mért adatok jellegét is, a 3.4. alfejezet pedig azt, hogy ezek az adatok miként lettek felcímkézve, ezzel egy referencia adathalmazt létrehozva. A 4. fejezet a szakirodalom elemzése mellett bemutatja, hogy hogyan történt az összegyűjtött adatok elemzése, külön kitérve a földrajzi, illetve a szenzoradatokra. Ezt követően pedig leírja, hogy hogyan lehet ezek összevonásával előállítani a későbbi rendszerek által igényelt információkat: a járat- és tevékenységmeghatározást. Az 5. fejezetben a dolgozat ismerteti az elemzett adatokat felhasználó információs szolgáltatást: ez a rendszer a kísérleti mérőrendszer tapasztalatai alapján tud a rendelkezésre álló adatok segítségével különféle információkat biztosítani. Elsőként a megvalósítható funkciókról esik szó (5.1. alfejezet), majd a dolgozat a kis felhasználószámmal működő, de sokkal egyszerűbben módosítható és bővíthető prototípus rendszert mutatja be (5.2. alfejezet). Itt áttekintésre kerülnek a további lehetőségek is arra vonatkozólag, hogy milyen irányokba továbbhaladva lehet bővíteni a jelenleg megvalósított funkciókat. A fejezet végén pedig a dolgozat áttekinti, hogy milyen lépéseket kell tenni egy széles felhasználói bázist kiszolgáló éles rendszer elkészítéséhez. Végül a 6. fejezet összefoglalja az elért eredményeket. 10
2. Közösségi közlekedési rendszerek A fejezet összefoglalja a közösségi közlekedés szervezésében használt, a dolgozat szempontjából releváns rendszereket (2.1. alfejezet), a jelenleg elérhető utazástervező szolgáltatásokat (2.2. alfejezet), továbbá bemutatja a rendszerek által használt adatok struktúráját (2.3. alfejezet).
2.1. Forgalomirányító és utastájékoztató rendszerek A forgalomirányító és utastájékoztató rendszerek integrált rendszerek, amelyek egy tömegközlekedési vállalat különböző feladatait végzik el. Ezek közé tartozik többek között a járművek és a személyzet beosztása, a járművek nyomon követése, irányítása, a menetrend megtervezése és betartatása, valamint az utastájékoztatás is. A német IVU Traffic Technologies AG megoldásait sok helyen használják a világban (pl. London [1], Berlin [2], Deutsche Bahn [3]; Magyarországon jelenleg a MÁV és a BKK használja). Ez egy modulárisan felépülő rendszer, melyet a megrendelő igényeire szabva szállít le az IVU. Többek között külön modul létezik a hálózat- és menetrendtervezésre (IVU.plan), jármű- és szolgálati beosztásra (IVU.vehicle, IVU.crew), járműkövetésre és forgalomirányításra (IVU.fleet), elektronikus jegyrendszer kezelésére (IVU.ticket), utastájékoztatásra (IVU.realtime) és statisztika alapú számlázásra (IVU.control).
2.1.1. Budapest forgalomirányítási és utastájékoztatási rendszere Budapesten a BKK (Budapesti Közlekedési Központ) a közlekedésszervezésért felelős szervezet, a tömegközlekedés irányítóiként ők rendelik meg a szolgáltatást az alvállalkozóktól (pl. BKV, Volánbusz, VT-Arriva), a jegyeladást és -ellenőrzést végzik, valamint a forgalomirányításért és az egységes utastájékoztatásért is felelősek. Ez utóbbi két ponton a BKK Futár (Forgalomirányítási és UtasTÁjékoztatási Rendszer) bevezetése nagy előrelépést jelentett az elmúlt években. Egyrészt forgalomirányítási szempontból megkönnyíti a diszpécserek munkáját, mivel a járművek pozícióját az eddigi, járművezetővel történő rádiós kommunikáció helyett már élőben látják a képernyőkön. Másrészt az utastájékoztatás is az így elérhetővé vált adatokkal történik, például köztereken elhelyezett kijelzők mutatják, hogy mikor várható a következő jármű indulása a megállóból, de ugyanezen információk az interneten keresztül is elérhetők. A rendszert a Synergon építette ki, és az IVU rendszerén alapul. A rendszer számára a járművekben található Futár egységek adnak információkat a járművekről, amelyek mobilinternetes vagy rádiós kapcsolattal kommunikálnak a központtal. [4]
11
2. ábra: BKK Futár fedélzeti egység (IVU.cockpit). (Forrás: [4]) A járművekbe szerelt egység a központtal kommunikálva folyamatosan közli a jármű pozícióját, vezérli az utastájékoztató rendszert, valamint kétirányú kommunikációt biztosít a diszpécser és a járművezető között.
3. ábra: A BKK Futár weboldala. [5] A weboldalon valós időben látszanak a járművek pozíciói és a menetrendi adatok, valamint az azoktól való eltérések.
2.1.2. A Kisalföld Volán forgalomirányítási és utastájékoztatási rendszere 2010 augusztusában kezdte el Győrben és Sopronban kialakítani az utastájékoztatási és forgalomirányítási rendszert a Kisalföld Volán és a Synergon, ami 2012 elején készült el. A járművek pozíciója itt is élőben követhető az interneten és a megállókba kihelyezett oszlopokon.
12
4. ábra: A Kisalföld Volán weboldala. [6] Győrben és Sopronban is megtekinthető az egyes autóbuszok útvonala, a járművek megállóba érkezési időpontja, valamint az aktuális pozíciója.
2.1.3. A MÁV forgalomirányítási és utastájékoztató rendszere A MÁV (Magyar Államvasutak) az IVU vasútra módosított rendszerét (IVU.rail), annak is az IVU.rail.plan, IVU.rail.vehicle és IVU.rail.crew modulját használja a vontatásszervezési és személyzetkiosztási feladatok irányítására. Ehhez kapcsolódik a MÁV Informatika által fejlesztett utastájékoztatási rendszer, aminek eredményeképpen 2011 augusztusa óta a vonatok pozíciója élőben követhető a MÁV Vonatinfó oldalán [7], illetve 2015 márciusa óta a Vonatinfó mobilalkalmazásban is [8].
5. ábra: A MÁV Vonatinfó oldala [9] és a Vonatinfó mobilalkalmazás [10]. Az oldal és az alkalmazás mutatja a magyarországi személyszállító vonatok pozícióját és esetleges késését. 13
2.2. Utazástervező rendszerek Az utasok szemszögéből az egyik legfontosabb feladat a tömegközlekedéssel kapcsolatban az utazástervezés: hogyan közlekedjen, ha a lehető leggyorsabban, legolcsóbban vagy a legkevesebb átszállással szeretne eljutni a céljához. Az ezen feladatot megoldó rendszereknek valamilyen módon (vagy exportált menetrendi adatokon keresztül, vagy pedig közvetlenül) kapcsolódniuk kell az előző alfejezetben bemutatott forgalomirányító és utastájékoztató rendszerekhez, ahonnan az ehhez szükséges menetrendi, illetve az élő adatokat be tudják szerezni. Az utazástervező alkalmazásokat megkülönböztethetjük aszerint, hogy egyetlen városra vagy szolgáltatóra specifikus szolgáltatást nyújtanak-e (mint például a BKK alkalmazásai vagy a MÁV Vonatinfó alkalmazása), vagy pedig globálisan szolgáltatnak (mint például a Google Maps vagy a Moovit mobilalkalmazás). Jelen alfejezet bemutatja, hogy egy kiválasztott nagyvárosban, Budapesten történő tömegközlekedéshez ma milyen népszerű webes, illetve mobil utazástervező rendszereket vehetünk igénybe. Manapság a legtöbb webes szolgáltatás számára elengedhetetlen, hogy rendelkezzen mobilalkalmazással is legalább a legnépszerűbb platformokon, melyek a legtöbb esetben rendelkeznek a weboldal fontosabb funkcióival. Az 1. és a 2. táblázat összefoglalja a jelenlegi népszerű, a budapesti közösségi közlekedésről információt nyújtó szolgáltatásokat webes, illetve mobil rendszereken, amikről az alábbiakban részletesebben is szó lesz.
2.2.1. Google Maps A Google Maps jelenleg az egyik legnépszerűbb térkép- és útvonaltervező szolgáltatás. 2011 júniusa óta a BKK és a Google együttműködésének köszönhetően a BKK által GTFS formátumban közzétett menetrend alapján lehetőség van a Google Maps segítségével tömegközlekedési útvonaltervezésre Budapesten is [11], 2014 novembere óta pedig az élő forgalmi adatok (például járművek késése, baleset miatti terelések) is megjelennek az oldalon. [12]
2.2.2. A BKK saját útvonaltervező szolgáltatása A BKK 2014-ben elérhetővé tette a saját útvonaltervező szolgáltatását a futar.bkk.hu oldalon, valamint a hozzá tartozó mobilalkalmazást, amik közvetlenül a Futár rendszerből származó élő adatokkal dolgoznak. Ezenkívül a szolgáltatás 2014 novembere óta a MOL Bubi közösségi kerékpáros rendszerrel is össze van hangolva. [5]
14
1. táblázat: Budapesti közösségi közlekedési útvonaltervező weboldalak Google Maps Bing Maps Here Maps
Menetrend igen igen nem
Útvonalterv igen igen igen
BKK Futár
igen
igen
BKK Info
nem
nem
Élő adatok indulási időpontok, rendkívüli események nincsenek nincsenek indulási időpontok, útvonaltervezés, élő járműpozíciók rendkívüli események
2. táblázat: A budapesti közösségi közlekedési menetrend és útvonaltervező alkalmazások áttekintése Rendszer
Menetrend
Útvonalterv
Élő adatok menetrend, rendkívüli események, járműpozíciók, útvonaltervezés menetrend, rendkívüli események
Android letöltés, értékelés
BKK Futár
Android, iOS, Windows Phone
online
online
Google Maps
Android, iOS
online
online
online
online
nincs
nincs
offline és online
offline és online
offline
nincs
rendkívüli események menetrend, járműpozíciók, útvonaltervezés nincs
offline
offline
nincs
50-100e, 4,1
online
online
nincs
10-50m, 4,2 (globális)
Bing Maps BKK Info Budapesti menetrend BPMenetrend Smart City Moovit
Windows Phone Android, iOS Android Android Android, iOS Android, iOS, WP
nincs
100-500e, 4,0
1-5 mrd, 4,3 (globális) 50-100e, 3,6 100-500e, 4,7 100-500e, 4,1
6. ábra: Webes útvonaltervező alkalmazások útvonaltervei ugyanarra az útvonalra és indulási időpontra. Balra: Google Maps, középen: Bing Maps, jobbra: BKK Futár 15
2.2.3. Mobilalkalmazások utazástervezéshez Ma az okostelefonok világszerte rohamosan terjednek. Magyarországon 2014 végén a 14 év feletti korosztály 39%-a rendelkezett ilyen készülékkel. Az okostelefonok használata leginkább a 40 év alatti korosztályra jellemző, nekik majdnem kétharmaduk használ okostelefont (a részletes statisztikák a 7. ábrán láthatók).
7. ábra: Az okostelefonok elterjedtsége Magyarországon. (Forrás: [13]) Bal oldalon a korosztályi eloszlás látható 2013-ban (szürke) és 2014-ben (zöld), jobb oldalon pedig a hagyományos (világoskék) és az okostelefonnal (sötétkék) rendelkezők aránya. 100 90 80 70 60 50 40 30 20 10
Android
iOS
SymbianOS
Windows Phone
2015. november
2015. augusztus
2015. május
2015. február
2014. november
2014. augusztus
2014. május
2014. február
2013. november
2013. augusztus
2013. május
2013. február
2012. november
2012. augusztus
2012. május
2012. február
2011. november
2011. augusztus
2011. május
2011. február
2010. november
0
Samsung Bada
8. ábra: Az okostelefonos operációs rendszerek elterjedtsége Magyarországon 2010 novembere és 2015 novembere között. (Forrás: [14]) 16
Magyarországon ma az Android a legnépszerűbb mobil operációs rendszer: a készülékek több mint 70%-án ez a rendszer fut, az okostelefonok 16%-án iOS, 9%-án pedig Windows Phone rendszer működik (8. ábra). Emiatt a magyar piacra tervezett alkalmazások nagy része elsősorban az Android rendszert célozza meg. Manapság minden digitális szolgáltatásnál nagy előny, ha létezik mobil változata is. Különösen igaz ez a közlekedéssel kapcsolatos tevékenységekre: amikor a felhasználó utazik, akkor a mobiltelefonján a legkényelmesebb utazást terveznie, megnéznie a menetrendet. Mobiltelefonos utazástervezésre több lehetőség is van, ezek többsége internetkapcsolatot igényel, de van offline tervezésre alkalmas alkalmazás is: –
Google Maps: a Google Maps szolgáltatás mobilalkalmazása az androidos készülékek többségén előretelepítve érkezik, illetve iOS rendszerre is letölthető, így a magyarországi okostelefonok döntő többségén megtalálható. A szolgáltatás élő internetkapcsolat segítségével tud útvonalat tervezni a menetrendi adatok alapján. [15]
–
BKK Futár: a BKK által kiadott mobilalkalmazás elérhető mindhárom nagy okostelefon platformon. A rendszer képes online utazást tervezni a valós idejű járműadatok figyelembe vételével, megjeleníteni a járművek pozícióit, valamint megtekinthetők rajta a becsült indulási időpontok megállókra és járatokra vonatkozóan is. [16]
–
BKK Info: az alkalmazás az éppen aktuális terelésekről, fennakadásokról tájékoztatja és értesíti a felhasználókat. Az alkalmazásban az utasok megadhatják, hogy melyek az általuk gyakran használt viszonylatok, és ha azokon történik valami rendkívüli esemény, akkor erről szól az alkalmazás. [17]
–
Budapesti Menetrend: az alkalmazást Szincsák Tamás készíti, jelenleg ez a legnépszerűbb és legmagasabbra értékelt budapesti menetrend és útvonaltervező alkalmazás a Google Play Store-on. Képes offline útvonaltervezésre is, de internetkapcsolat esetén a valós idejű adatokat is megjeleníti, illetve felhasználja. [18]
–
BPMenetrend: az alkalmazás offline, statikus menetrendet biztosít a felhasználóknak. Ez volt az első androidos, internetkapcsolat nélkül is működő menetrend alkalmazás, így jelenleg is sok felhasználó használja. [19]
–
Smart City: az alkalmazás offline menetrendet és útvonaltervezést biztosít Android és iOS rendszerekre. [20]
–
Moovit: egy közösségi visszajelzéseken alapuló alkalmazás Android, iOS és Windows Phone rendszerekre. Rendelkezik utazás közben használható funkciókkal is, azonban az élő menetrendet és az előre bejelentett tereléseket se mind ismeri. [21]
A legnépszerűbb alkalmazások képernyőképei a 9. ábrán láthatók.
17
9. ábra: A különböző mobilos útvonaltervező alkalmazások felületei Android rendszeren ugyanarra az útvonalra és indulási időpontra. Balról jobbra: Google Maps, Budapesti menetrend, Smart City, BKK Futár
2.2.4. Közösségi útvonaltervezés és közlekedésszervezés Az adott alkalmazást használó felhasználók mobiltelefonos adatainak felhasználása az autós útvonaltervezésben már évek óta bevett gyakorlat. Az egyik ilyen a Google Maps autós útvonaltervezése, ami a felhasználók mobiltelefonjai által küldött adatok, a készülékek haladási sebessége alapján próbálja meghatározni, hogy hol van dugó vagy forgalomkorlátozás a városban – ahol az emberek általában lassan haladnak, arra kevésbé tervez útvonalat. A Google 2013 júniusában megvette a Waze-t, egy közösségi útvonaltervező rendszert. Ennek lényege az, hogy a térképen az autósok egy mobil alkalmazás segítségével feltüntethetik, hogy hol van baleset, forgalomkorlátozás vagy dugó a városban. 2013 augusztusa óta a Google útvonaltervezője ezeket a bejelentéseket is figyelembe veszi útvonaltervezéskor, és értesíti az autósokat az eseményekről, illetve kerülőutakat tervez. [22] Másik, jelenleg is gyakran használt módszer a mobiltelefonok adatainak felhasználására az, amikor a közlekedési szolgáltató a mobilszolgáltatóktól szerzett, általában anonim cellainformációs adatok alapján tud információkhoz jutni a közlekedés általános működéséről és a város lakóinak mozgásáról. Ilyen rendszerek például az IBM Research AllAboard rendszere [23], de hasonló témában végeztek kutatásokat Tokióban [24], illetve Németországban a Deutsche Bahn esetében is [25].
2.3. Közösségi közlekedési adatok A közösségi közlekedési adatok felépítése több, egymáshoz kapcsolódó adatforrásként fogható fel. Ez az alfejezet először tisztáz néhány tömegközlekedési alapfogalmat, ami szükséges az adatok leírásához, majd pedig bemutatja, hogy ezek az adatok jelenleg milyen formátumokban érhetők el Budapesten, illetve azok milyen adatokat tartalmaznak.
18
2.3.1. Alapfogalmak A közösségi közlekedésben, és ezáltal az adatok leírásában is használatos alapfogalmak a következők: A viszonylat (angolul route) a BKK üzletszabályzatában található definíció szerint „két végpont között adott útvonalon és megállókkal és/vagy fel- és leszállópontokkal meghatározott közlekedési szolgáltatás, amelyet a viszonylatjelzés (szám, betű vagy név) különböztet meg a más hasonló szolgáltatásoktól” [26], azaz például a 19-es villamos vagy a 7-es busz. A járat vagy menet (angolul trip) egy jármű menetrend szerinti közlekedése egy adott útvonalon, azaz például a 15:05-kor a Batthyány téri végállomásáról induló és 15:26-kor Kelenföld vasútállomásra érkező 19-es villamos. A jármű (angolul vehicle) a fizikai jármű, például az MHU-710 rendszámú Mercedes Citaro autóbusz vagy a 1419-es pályaszámú Ganz csuklós villamos. Budapesten, ha két vezetőállása van egy járműnek két külön Futár egységgel (például villamosok), akkor is egy járműnek látszik a rendszerben, viszont ha két különböző pályaszámú villamos van összecsatolva (például Budapesten általában a Tátra villamosok), akkor mindig az látszik a rendszerben, amelyikben a villamosvezető ül. Az adatbázis szempontjából megállónak (angolul stop) számít minden olyan helyszín, ahol a menetrend szerint járművek megállnak, azaz többnyire minden megállótáblához külön azonosító tartozik. Ez alól Budapesten kivételek azok a többvágányú villamos-végállomások, melyeknek közös megállóazonosítójuk van, ha onnan csak az egyik irányba indulnak járművek. Így egyértelműen meghatározható a jármű menetrendjében minden érintett megálló. A megállók a közeli átszállási lehetőségek alapján csoportokba tartoznak, egy csoportba Budapesten általában az azonos nevű megállók tartoznak (pl. a Deák Ferenc tér összes megállója).
2.3.2. Adatforrások Budapesten A BKK a fejlesztők számára 2011 júniusa óta elérhetővé teszi a statikus menetrendet GTFS formátumban, 2014-től pedig elérhetők az élő járműadatok is a Futár API-n keresztül. A GTFS (General Transit Feed Specification) a Google által kifejlesztett, csv alapú adatformátum tömegközlekedési menetrendek leírására. [27] Tartalmazza többek között a viszonylatok és a megállók listáját, útvonalait GPS koordinátákkal megadva, illetve a pontos érkezési és indulási időpontokat naptári napokra lebontva. Az eredeti változatnak többféle kiegészítése létezik, ezek segítségével különböző funkciók adhatók hozzá, például viteldíj, az állomások bejáratainak vagy vasút esetében a vágány számának jelölése. A budapesti GTFS fájl a fent leírt attribútumok mellett tartalmaz extra információkat is, például a járművek alacsonypadlósságáról.
19
10. ábra: A BKK tömegközlekedési hálózata a GTFS menetrend alapján. Az ábrán kék vonallal láthatók azok az útvonalak, amelyeken menetrend szerinti járművek közlekednek. A GTFS-RT vagy GTFS-realtime a Protocol Buffersen alapuló bináris fájlformátum, amelynek segítségével a tömegközlekedési szolgáltatók egységes formában tehetik közzé a járművek élő információit. [28] A formátumot a Google fejlesztette ki, elsősorban a valós idejű járatinformációk és a rendkívüli események Google Maps térképen történő megjelenítéséért. A BKK 2014 novemberében tette elérhetővé a budapesti GTFS-RT feedet a Google számára, de ez kívülálló fejlesztők számára nem elérhető.
11. ábra: A BKK járművei által küldött pozíciók egy hétköznapon. Sötétebb vonallal látszódnak a járművek által sűrűbben érintett útvonalak.
20
A BKK Futár API a BKK Futár online felülete által is használt API, amit felhasználnak az élő adatokat biztosító alkalmazások is. Lekérdezési lehetőséget biztosít a járművek valós idejű pozíciójához, az egyes megállókból induló járművek listájához (ami a kültéri kijelzőkön is látható), valamint az egyes járművek becsült érkezési és indulási idejéhez. Emellett visszaadja azt is, ha egy vonalon a menetrendhez képest módosult valami (például terelések, nem közlekedő járművek, pótlóbuszok), de a MOL Bubi állomások pozícióit és ezek telítettségét is ki lehet nyerni a segítségével. [29]
2.3.3. A budapesti közlekedési adatok tartalma A statikus menetrendi adatok a BKK GTFS adatbázisából származnak, és a következő adatok relevánsak belőle a dolgozat szempontjából (a pontos fogalmak a 2.3.1. alfejezetben vannak leírva): 3. táblázat: A megállók adatai
Azonosító Megjelenítési név Koordináták
Magyarázat Minden megállónak egyedi, lásd még 2.3.1. Ami a kijelzőn szerepel Szélességi és hosszúsági
Példa „008591”: Szent Gellért téri villamosmegálló észak felé „Szent Gellért tér M” „47,483651; 19,053524”
4. táblázat: A viszonylatok adatai
Azonosító Viszonylatjelzés Típusa
Magyarázat Viszonylatjelzésből előállítva Ami a kijelzőn szerepel Normál esetben (amikor nincs például villamospótlás) milyen járművek közlekednek rajta.
Példa „1070”: 107-es busz „3190”: 19-es villamos „19”, „M4”, „H7” „Autóbusz”, „Villamos”, „Metró”
5. táblázat: A járatok (menetek) adatai Magyarázat Azonosító Viszonylat azonosító Célállomás neve Útvonal koordinátái Járat menetrend szerinti megállói
4. táblázat alapján Ami a kijelzőkön szerepel Végállomástól kezdve a pontok listája Menetrend szerinti érkezési és indulási időpontokkal
Példa „B40144156”: 14:12-kor Kelenföld vasútállomástól induló és 14:32-kor Deák Ferenc térre érkező 49-es villamos. „3490”: 49-es villamos „Deák Ferenc tér M” „47,46574; 19,02190” „47,46623; 19,02197”… „007967: ind. 14:12:00” „F02039: érk. és ind. 14:13:00”…
A Futár API-n keresztül van lehetőség a valós idejű információk lekérésére (amellett, hogy a GTFS által tartalmazott információk többségét is rendelkezésre bocsátja):
21
6. táblázat: Az élő járműinformációk Járműpozíció időpontja Jármű azonosítószáma Viszonylat azonosítója Járat azonosítója Jármű típusa Jármű fajtája Jármű koordinátái Jármű irányszöge Jármű rendszáma vagy pályaszáma Következő megálló azonosítója Jármű relatív pozíciója a két megálló között Jármű állapota
Magyarázat Az az időpont, amikor a járműadatok készültek Futár azonosítója a járműnek (lásd még a 2.3.1-ben) Melyik viszonylaton dolgozik a jármű, 4. táblázat alapján Melyik járatot szolgálja ki a jármű Milyen típusú jármű Valójában milyen jármű közlekedik (pl. villamospótlás esetén autóbusz) Szélesség, hosszúság Északhoz képest hány fokos irányba halad
Példa „2015.11.28. 14:13:40” „4420”: A 1316-os pályaszámú Ganz csuklós villamos Futár készüléke „3490”: 49-es villamos „B40144156”: lásd az 5. táblázatot „Ganz csuklós” villamos, „Volvo7900A Hybrid” autóbusz „Autóbusz”, „Villamos” „47,468822; 19,024391” „55,6” „V1316” (villamos), „MYK398” (autóbusz), „T0609” (trolibusz) „F02040”: Csóka utca
Hány százalékát tette meg az útnak a jármű az előző és a következő megálló között A jármű úton van, vagy pedig megállóban áll-e (ajtók nyitva)
„6%” „Úton”, „Megállóban”
A Futár API-n keresztül elérhető, a statikus menetrendben nem megtalálható további adatok: –
A járatok érkezési és indulási időpontjainál egy becsült érkezési és indulási idő is szerepel
–
A megállók csoportosítva vannak, így az azonos csomóponthoz tartozók könnyen lekérdezhetők
–
Lekérdezhető egy megállóba érkező vagy induló járatok azonosítója, illetve menetrend szerinti és becsült érkezési és indulási időpontja
–
Minden viszonylathoz lekérdezhető, hogy milyen zavarok vagy módosítások (pl. terelés, megálló kihagyás stb.) tartoznak hozzá:
Mettől meddig érvényes a módosítás
Melyik megállókat érinti
Szöveges leírás a zavarról (angol és magyar nyelven)
A következő oldalon a 12. ábra bemutatja, hogy ezek az adatok hogyan kapcsolódnak egymáshoz.
22
12. ábra: A tömegközlekedési adatok kapcsolatai egymással. Kék színnel a statikus GTFS menetrendi adatok láthatók, zöld színnel pedig a Futár API-n keresztül hozzáférhető valós idejű adatok.
23
3. Kísérleti mérésadatgyűjtő rendszer A dolgozatban szereplő módszerek pontos kialakításához és ellenőrzéséhez elengedhetetlen volt, hogy legyenek okostelefonnal mért adatok, amelyek hétköznapi felhasználás során keletkeznek. Ennek eléréséhez a dolgozat részeként elkészült egy androidos okostelefonos alkalmazás, ami rögzíti és feltölti egy szerverre az adatgyűjtő felhasználók készülékeinek hely- és mobil szenzoradatait. Az adatgyűjtés elsősorban a budapesti tömegközlekedési rendszerre készült, de a helyspecifikus módosítások (pl. a Futár rendszer adatainak lecserélése másik város élő járműadataira) után más városokban is működőképes lenne. A rendszer segítségével két szakaszban, először másfél hónapon keresztül (2014. október– november) 18 készülékkel, majd egy kéthetes intenzív időszakon keresztül (2015 márciusában) 40 készülékkel történt adatgyűjtés a dolgozatban bemutatott módszerek előállításához. Az ez idő alatt összegyűlt adatok nagy jelentőséggel bírnak adatbányászati és kutatási szempontból is. A fejezet bemutatja a kísérleti mérésadatgyűjtő rendszer felépítését és működését (3.1. alfejezet), az adatgyűjtő szoftvert (3.2. alfejezet), a mért adatok alapvető tulajdonságait (3.3. alfejezet), valamint az annotáló rendszert, melynek segítségével a referenciaadatokat lehetett előállítani (3.4. alfejezet).
3.1. A mérésadatgyűjtő rendszer architektúrája és implementációja A mérésadatgyűjtő rendszer egy androidos mobilalkalmazásból és egy szerverből áll. A mobilalkalmazást az adatgyűjtő felhasználók telepíteni tudják a telefonjukra vagy tabletjükre. Az alkalmazás elindítása után a rendszer rögzíti az általuk megtett útvonalat (földrajzi adatokat), illetve a készülék hardveres szenzorai által nyújtott adatokat. Az adatgyűjtés befejezése után megfelelő hálózati kapcsolaton ezeket az adatokat a készülék továbbítja az adatgyűjtő szervernek, ami eltárolja azokat rendezett formában a későbbi felhasználás céljaira. Emellett az adatgyűjtő szerver folyamatosan rögzíti a BKK élő járműadatait, illetve a statikus menetrendet is. A mérésadatgyűjtő rendszer mobilalkalmazása Android 4.0-s vagy újabb rendszereken érhető el. Az adatgyűjtők számára a Google Play Store-on keresztül lett közzétéve, így biztosítva azt, hogy a folyamatos frissítések, funkcióbővítések minimális felhasználói beavatkozás mellett települhessenek. A szerver esetében felmerült, hogy ezt egy felhő alapú szolgáltatás biztosítsa, de a kevés felhasználó és a nagy adatmennyiség miatt ez nem lett volna költséghatékony megoldás. Mivel nem volt szükség a szerver stabil és teljesen folyamatos működésére (egy esetleges hálózatkiesés esetén a mobil készülékek megőrzik az adatokat, és egy későbbi időpontban feltöltik azokat),
24
ezért egy kis fogyasztású szervergép és egy közepes sebességű internetkapcsolat segítségével is működőképes,
olcsón
üzemeltethető
rendszert
lehetett
felállítani,
így
elkerülve
a
felhőszolgáltatások magasabb adattárolási költségét. Az adatgyűjtéshez használt szerver egy Windows Server 2012 R2-t futtató Mini-ITX alacsony fogyasztású számítógép volt, amelyen egy PHP alapú weboldal várta a felhasználók által feltöltött adatokat, és töltötte bele egy PostgreSQL adatbázisba. A Futár adatok rendszeres, automatikus adatbázisba mentését pedig egy Python alapú szolgáltatás biztosította.
13. ábra: A kísérleti mérésadatgyűjtő rendszer architektúrája. A piros színnel jelölt modulok a dolgozat keretében elkészített részek, a fekete színnel jelöltek pedig a meglévő rendszerek, amelyekből az adatgyűjtés történik.
3.2. Adatgyűjtő szoftver Az adatgyűjtés egy ismerősi körben terjesztett Androidos mobilalkalmazással valósult meg. Ennek segítségével 40 készülékkel (33 különböző típussal) gyűjtött adat érkezett. A készülékek sokszínűsége a későbbi felhasználás szempontjából fontos, hogy ki lehessen szűrni azokat a módszereket, amelyek csak bizonyos képességű eszközökkel működnek. Ez különösen a szenzoradatoknál érdekes, mivel az eltérő típusú telefonokban különböző gyártmányú és képességű szenzorok vannak.
3.2.1. Az adatgyűjtés ütemezése Az adatgyűjtő szoftver a telefon által biztosított mindent adatot (GPS és hálózatalapú helyadatot, valamint a készülékekben megtalálható gyorsulásmérő, gravitációs és mágneses szenzor, illetve a giroszkóp adatait) rögzíti az adatgyűjtés elindítása után egészen a leállításáig. A részletes adatok segítségével egyrészt könnyebb volt megvalósítani a szenzoros tanulást, illetve meg lehetett vizsgálni, hogy ezeknek az adatoknak mely részeire van szükség a továbbiakban.
25
Az információs rendszer mobilalkalmazásánál már fontos lesz, hogy az adatgyűjtés minél kevesebb energiát, illetve adatforgalmat használjon (erről bővebben az 5.2.4. alfejezetben lesz szó). Ez azonban csökkenti az összegyűjtött adatmennyiséget, ami a mérésadatgyűjtő rendszernél hátrány, mivel várhatóan ront a detekciók és a tanítás hatékonyságán. A későbbiekben fontos azt is megvizsgálni, hogy milyen egyszerűsítések mekkora mértékben csökkentik ezeknek a funkcióknak a teljesítőképességét. A felhasznált energia és adatmennyiség csökkentése többféleképpen is megoldható. Egyrészt a szenzoradatok szakaszos rögzítésével, azaz azzal, hogy az alkalmazás nem rögzít minden adatot, csak adott időközönként; másrészt ritkább mintavételezési frekvencia használatával, harmadrészt pedig azzal, ha nem kér olyan sűrűn helyadatokat, mint azt a kísérleti rendszer adatgyűjtő alkalmazása teszi.
14. ábra: Az adatgyűjtő alkalmazás felülete. Bal oldalon a főoldal látszik, itt lehet elindítani és leállítani az adatgyűjtést, jobb oldalon pedig az alkalmazás beállításai.
3.2.2. A tevékenység rögzítése és az adatok feltöltése A felhasználó az adatgyűjtő alkalmazás használata közben jelezheti az aktuális tevékenységét. Ekkor egy listából kiválaszthatja, hogy éppen mit csinál (például felszállt járműre vagy gyalogolni kezdett). A felhasználói felület a 15. ábra bal oldali képernyőképén látható. A gyűjtött adatokat az alkalmazás (a beállításoktól függően) mobilinterneten vagy WiFi hálózaton feltölti a szerverre. Az alkalmazás figyel arra, hogy az adatok mindenképpen feltöltődjenek: addig nem törli a készülékről az adott adatsort, amíg a szerver nem nyugtázta, hogy megérkeztek az adatok. 26
3.2.3. Adatvédelem Az adatgyűjtés anonim módon történt, az adatok mellé az alkalmazás csak egy készülékazonosítót küldött el. Azonban mivel a felhasználók a tipikus helyadataik segítségével egyértelműen beazonosíthatók még komoly anonimizáció mellett is, fontos szempont volt, hogy csak olyan információk kerüljenek elküldésre, amelyekhez ők hozzájárulnak. Éppen ezért az adatgyűjtő alkalmazás önállóan nem működik, csak ha a felhasználó szándékosan elindítja, és csak addig rögzíti az adatokat, amíg le nem állítja. A rögzítés futásáról a készülék egy értesítésen keresztül folyamatosan tájékoztatja a felhasználót.
15. ábra: A tevékenységrögzítő képernyő (balra) és az adatgyűjtők toplistája (jobbra). Az óránként frissülő listában szerepel az egyes készülékekkel rögzített útvonalak hossza, valamint időtartama. A lista alapvetően anonim, egy 4 karakteres azonosító jelöli az egyes készülékeket, de volt lehetőség egy rövid nicknév megadására is azoknak, akik nem akartak névtelenek maradni.
3.2.4. Adatgyűjtők motiválása Az első adatgyűjtési időszak után több olyan visszajelzés is érkezett, hogy szívesen rögzítettek volna még több útvonalat a felhasználók, de gyakran megfeledkeztek bekapcsolni az alkalmazást. Ezért a második időszakra módosítva lett az alkalmazás, belekerült egy kikapcsolható lehetőség, hogy ha mozgást érzékel a készülék, akkor egy értesítéssel kérje az adatgyűjtés bekapcsolását. Emellett szükség volt a felhasználók motiválására is: ennek érdekében az alkalmazás ki lett bővítve azzal, hogy jelezze az aktuális felhasználó által gyűjtött adatok mennyiségét, valamint készült egy anonimizált toplista (15. ábra), ahol összehasonlíthatták egymással a rögzített
27
távolságot és az utazással töltött időt. Így az adatgyűjtők megbizonyosodhattak róla, hogy az adatok, amiket gyűjtenek, nem vesznek el, azonnal feldolgozásra is kerülnek, valamint verseny jelleggel látják azt is, hogy a többiekhez képest hogyan teljesítettek. Itt a megjelenített távolságnál figyelni kellett arra, hogy csak a reális távolságadatok kerüljenek bele a statisztikába: emiatt csak a GPS pontosságú adatok kerültek beleszámításba (például metrón történő utazás nem), illetve a hirtelen pozícióugrások (100 km/h feletti sebességérték esetén) szintén kimaradtak a távolság összegzéséből.
3.2.5. Időszinkronizáció Az első lépésben gyűjtött adatok elemzése során kiderült, hogy a telefonok órájának pontossága nagyon fontos a pontos helymeghatározás szempontjából: már egy 5 másodperces eltérés is 70 méteres távolságkülönbséget tud okozni 50 km/h-s sebesség mellett. Ezzel az esetek nagy részében nem volt gond köszönhetően a telefonok automatikus időbeállításának, azonban volt néhány készülék, ahol jelentős (10-15 másodperces) csúszás volt az időadatokban. Emiatt szükségessé vált egy időszinkronizációs mechanizmus beleépítése az alkalmazásba. A jelenlegi megoldás az adatgyűjtő szervertől kéri le rendszeresen a pontos időt, és ezzel korrigálja az aktuális készülékidőt a gyűjtött adatoknál. Amire itt fontos volt figyelni, hogy adatrögzítés közben ne történhessen módosítás a használt időben, mivel ez felboríthatná az adatsorok sorrendiségét, így nagyobb problémákat okozva, mint amit maga az órák elcsúszása okoz.
3.2.6. További gyűjthető adatok A gyűjtött adatok körének bővítése egy fontos, még nem elvégzett feladat: legfontosabb a készülék által észlelt környező WiFi- és cellahálózatok adatainak rögzítése lenne: jelenleg az Android rendszer a helyet megpróbálja ezekből az adatokból megtippelni, de ez gyakran nem sikerül tökéletesen, ezen adatok pedig sokat jelenthetnek például a metrón történő utazások detektálásánál.
3.2.7. Tapasztalt problémák Sajnos néhány készülék szenzorai nem működtek tökéletesen az API leírás szerint: a szélesebb körben elkezdett adatgyűjtéskor derült ki, hogy bizonyos készüléktípusok nem hajlandóak a szenzoradatokat biztosítani úgy, ahogyan azt a készülékek jelentős többsége teszi. A hiba a tapasztalatok alapján csak az eszköz típusától függött (főként régebbi Samsung és Sony készülékek esetében fordult elő), a használt Android rendszerverzió nem játszott szerepet benne.
28
3.3. Gyűjtött adatok A kísérleti rendszerben elsősorban a földrajzi helyadatok és a mobiltelefonos szenzoradatok gyűjtése volt fontos. Ezeket az adatokat egy androidos mobilalkalmazás – a felhasználó által az alkalmazás telepítésekor történt engedélyeztetés után – eléri, így a feltelepített program képes ezeket egy helyi adatbázisban összegyűjteni, majd pedig feltölteni.
3.3.1. Földrajzi adatok Manapság az okostelefonok mindegyike rendelkezik valamilyen helymeghatározó képességgel. A legtöbb készülékben van GPS modul, valamint különböző hálózati alapú helymeghatározó lehetőségeket is biztosítanak szoftveresen. Ilyen például a WiFi hálózatok vagy a mobil cellainformációk alapján történő helymeghatározás, amit az ismertebb okostelefonos operációs rendszerek (például Android, iOS, Windows Phone) beépítetten támogatnak. Ezek általában kevésbé pontosak, mint a GPS alapú helymeghatározás, viszont kevesebb energiát fogyasztanak, illetve olyan helyeken (pl. épületekben, föld alatt) is viszonylag gyenge, de azért használható pontosságú adatokat adnak, ahol a környezet árnyékolása miatt a műholdakat használó GPS technológia nem használható.
16. ábra: Gyűjtött helyadatok és a járművek útvonalai Budapesten. Kék színnel a felhasználók által rögzített pontok, piros színnel pedig a menetrendi útvonalak szerepelnek. Megfigyelhető, hogy a metróvonalak mentén érkezett adatok csak szakaszosan vannak jelen. Ennek oka, hogy mivel a föld alatt nincs elérhető GPS adat, csak a cella- és WiFi információkra tud hagyatkozni az adatgyűjtő alkalmazás a helymeghatározáshoz. 29
A kísérleti mérésadatgyűjtő alkalmazás használatával a felhasználók több mint 1 200 000 adatpontot gyűjtöttek. Az adatpontok nagy része, 1 100 000 pont GPS alapú mérésből, a többi WiFi és cellainformáció alapú mérésből származik. Ennek az aránynak az az oka, hogy a GPS adatok sokkal gyakrabban (jó vétel esetén akár másodpercenként) érkeznek, míg a WiFi és cellainformáció alapú helyadatok jóval ritkábban módosulnak. A készülék pozícióját az adatgyűjtő rendszer a lehető legpontosabban próbálja meghatározni. Ehhez azt kéri a rendszertől, hogy lehetőleg másodpercenként küldjön új helyadatot, ha az
Előfordulások száma
megváltozik.
0
0,5
1
1,5
2
2,5
3
3,5
4
4,5
5
5,5
6
6,5
7
7,5
8
8,5
9
Időtartam (mp)
17. ábra: Az adatgyűjtő program által gyűjtött helyadatok sűrűsége. A vízszintes tengelyen az egymást követő adatpontok időbeli távolsága szerepel. Amint az a 17. ábrán is látszik, ez az adatok nagy részénél teljesül is, a beérkezett adatok alapján viszonylag sűrűn, általában 1 másodpercen belül történt helyadat frissítés. Néhány készüléknél fordult csak elő, hogy ezt nem tudta teljesíteni, ekkor kb. 5 másodpercenként küldött új helyadatot. Mivel a helyadatok gyűjtése egy viszonylag energiaigényes feladat, ezért egyrészt az időközök ritkításával, másrészt a helyadatok pontosságának csökkentésével (például WiFi vagy mobilcella alapú helymeghatározás a GPS alapú helyett) jelentősen kisebb energiaigényűvé válhat az alkalmazás. A gyűjtött adatok sebesség alapján is megvizsgálásra kerültek, ennek eredménye a 18. ábrán látható. A hisztogram alapján az adatok jellegbeli eloszlása meghatározható: megközelítőleg 650 000 db közel 0 sebességű adatpont (várakozás vagy megállás), 170 000 1-10 km/h-s sebességű adatpont (gyaloglás vagy lassú utazás), 50 km/h-ig pedig közel azonos mennyiségű magasabb sebességű utazás közben gyűjtött pontot mértek az adatgyűjtők.
30
60-70
50-60
40-50
30-40
20-30
10-20
1-10
0
ezer
Adatpontok száma
700 600 500 400 300 200 100 0
Sebesség (km/h)
300
300
250
250
Mintavételi frekvencia
Mintavételi frekvencia
18. ábra: A sebességértékek eloszlása a GPS-szel mért adatoknál
200 150 100 50 0
200 150 100 50 0
Készülékek
Készülékek
300
300
250
250
Mintavételi frekvencia
Mintavételi frekvencia
19. ábra: A gravitációs szenzor (balra) és a giroszkóp (jobbra) átlagos mintavételi frekvenciájának eloszlása a különböző készülékek esetén.
200 150 100 50 0
200 150 100 50 0
Készülékek
Készülékek
20. ábra: A gyorsulásmérő (balra) és a mágneses szenzor (jobbra) átlagos mintavételi frekvenciájának eloszlása különböző készülékek esetén. A mágneses szenzorok általában sokkal ritkábban adnak adatot, mint a gyorsulásmérő és a giroszkóp. 31
3.3.2. Gyorsulásmérő és más szenzorok A gyűjtött szenzoros adatok a gyorsulásmérő, a gravitációs, a mágneses és a giroszkóp szenzortól származnak, természetesen csak akkor, ha a készülék rendelkezik ezekkel az érzékelőkkel. Az adatokat a különböző módszerek kipróbálásának érdekében a kísérleti rendszerben a lehető legpontosabban próbálta gyűjteni az alkalmazás. Amint az a 19. és a 20. ábrán látható, a szenzoroktól érkező mintavételi frekvencia erősen készülékfüggő volt, de a jobb készülékek képesek voltak átlagosan kb. 150–200 Hz-es frekvenciával biztosítani a mintavételt, ami elegendő pontosságot biztosít a hatékony tevékenységfelismeréshez. Az adatokon látszik, hogy a gravitációs és a gyorsulásmérő szenzor adatai fizikailag ugyanabból az eszközből származnak, mivel szinte teljesen megegyező az eloszlásuk.
3.3.3. Tömegközlekedési adatok A jármű meghatározását végző algoritmusnak feladata végrehajtásához szüksége van a járművek valós idejű pozícióira ahhoz. Ez a Budapesten alapuló kísérleti rendszerben a BKK Futár API élő járműadatainak folyamatos mentésével lett megvalósítva, mivel a GTFS-RT feed jelenleg fejlesztők számára nem elérhető. Emellett hasznos az olvasható eredmények szempontjából a statikus (jelen esetben GTFS alapú) menetrend is, amivel összekapcsolva a felhasználó számára könnyebben értelmezhető módon (pl. viszonylatszámot, útirányt kiírva) megjeleníthetők az eredmények. Ezek az adatok emellett kiegészíthetők a Futár API által adott extra információkkal, például a megállócsoport azonosítójával, illetve esetleges meg nem hirdetett változások esetén a rendkívüli járatok információival. Ezeket az adatokat elég központilag, egyszer lementeni, így ezeket nem a felhasználók készülékei,
Előfordulások száma
hanem a központi szerver mentette.
1
3
5
7
9
11
13
15
17
19
21
23
25
27
29
31
33
35
37
Időtartam (mp)
21. ábra: Egy adott jármű Futár helyadatainak sűrűsége. A vízszintes tengelyen az egymást követő adatpontok időbeli távolsága szerepel. 32
3.4. Referencia eredmények előállítása Ahhoz, hogy a későbbiekben ki lehessen értékelni a különféle adatelemzések teljesítményét, szükséges előállítani egy olyan annotált adathalmazt, ahol ismert, hogy mi az elvárt eredmény. Ezen adathalmaz elkészítéséhez rendelkezésre állnak az adatgyűjtők által biztosított kézi annotációk, valamint a legtöbb esetben az útvonalból ki lehet találni, hogy ki merre járt, és ez alapján kézzel ki lehet találni a használt járműveket. Ebben az esetben is nehézséget okoz azonban, hogy pontosan melyik járattal utazott egy felhasználó, ha azon a szakaszon pár percenként követik egymást a különböző járművek.
3.4.1. Utazáslista előállítása A referencia eredmények előállításához először is szükséges volt az egyes utazásokat különválasztani egymástól és meghatározni őket a felhasználók által a szerverre feltöltött ponthalmaz alapján. Ez történt egyrészt értelemszerűen az eszköz azonosítója alapján, másrészt pedig az így létrejött eszköztrajektóriák idő alapján történő feldarabolásával. Egy felhasználó utazásainak elkülönítésénél szempont volt, hogy időnként ritkán jönnek adatok (például metró használata esetén, különösképpen, ha nincs engedélyezve a hálózat alapú helymeghatározás), ezeknél hasznos, ha nem történik szétvágás, viszont az se praktikus az adatok annotálásának szempontjából, ha hosszabb megállások, illetve oda-vissza utazások vannak egy útvonaldarabban. Első megközelítésben egy útvonal jelenleg akkor van két részre vágva, ha fél óránál hosszabb időn keresztül nem érkezett új helyadat a készüléktől, de ezt a későbbiekben finomítani lehet szükséges (például bekapcsolva maradt adatgyűjtés esetén így különböző utazások is egybefüggőként jelenhetnek meg). Ezt a szétdarabolást hasznos lenne folyamatosan végezni. Ekkor azonban felmerül problémaként, hogy honnan tudhatja a daraboló algoritmus, hogy egy adott utazásnak vége lett, vagy csak még nem töltötte fel a felhasználó a későbbi (esetleg korábbi vagy közbülső) adatait. Erre megoldás lehet, hogyha a mobilalkalmazás, amennyiben fel van töltve az összes helyadat a készülékről, küld egy jelzést az adatgyűjtő szervernek, és ha ez a jelzés legalább a vágáshoz használt idővel később volt, mint az utolsó beérkezett adat, akkor biztosak lehetünk abban, hogy az az utazás befejeződött, és eltárolhatjuk azt, mint megtörtént utazás.
3.4.2. Annotáló felület Azért, hogy egy pontos és nagyméretű referencia utazáshalmazt lehessen létrehozni, szükséges volt egy olyan felületet létrehozni, amelyen az egyes utazások elkülönítve szerepelnek, és jól átlátható módon látszódnak a beérkező adatok. Annak érdekében, hogy több ember is tudjon dolgozni ennek a referencia annotációnak az előállításával, az annotáló felület egy HTML5 alapú weboldalként lett megvalósítva.
33
Ezen a felületen látszódik az anonimizált utazások listája, néhány mérőszámmal együtt (megtett távolság, rögzítés hossza, helyadatok pontossága).
22. ábra: Az adatgyűjtők által gyűjtött útvonalak listájának részlete az annotáló felületen Minden egyes útvonalhoz tartozik egy térkép, ahol látható az utas útvonala, a készüléke által rögzített pontok. Ezek azonban nem lesznek minden esetben teljes útvonalak, például a metróval megtett szakaszok a pontatlan helyadatok miatt gyakran hiányoznak a térképről (amint az a 23. ábrán is látható). Ebben az esetben lehet ezeket kézzel jelölni (az esetek többségében egy, a város közlekedését ismerő ember számára egyértelműek a helyzetek, például az, hogy az ábrán látható esetben a Határ út és a Népliget között az M3-as metróval közlekedett az adatgyűjtő). A térkép alatt szerepel egy sebesség-idő grafikon (lásd 24. ábra). Itt, amennyiben GPS pontosságú volt a mérés adott szakasza, zöld mezőben látszik a felhasználó sebessége, amikor pedig a műholdas jelek hiányában csak hálózat alapú, pontatlan helyadatokat biztosított a készülék, akkor sárga sáv látszik. Pirossal jelzi azt a grafikon, ha egy adott helyen ez sem volt elérhető (például nincsen a felhasználónak mobilinternete vagy a szolgáltatás le van tiltva a készüléken). A grafikonon ki lehet jelölni bizonyos szakaszokat, amelyek ekkor a térképen színesen szintén kiemelésre kerülnek, így rá lehet találni azokra a helyekre, ahol az utas sokáig időzött, például egy megállóban várakozott, ezáltal könnyebben be lehet azonosítani a fel- és leszállási helyeket, valamint az utas tevékenységét is. Ezeken kívül a felületen megjelenik még a későbbiekben, a 4.1.2. fejezetben bemutatott elemzés nyers eredménye is (25. ábra), amely a felhasználó helyadatait a járművek Futár alapú helyadataival veti össze, és minden időpillanathoz minden, a közelben levő járműhöz kiszámol egy pontszámot, ami azt mutatja meg, hogy egy hosszabb távra visszatekintve mennyire volt közel egymáshoz a felhasználó és a jármű. Ennek segítségével a pontos jármű a legtöbb esetben könnyen meghatározható, a fel- és leszállási hely viszont sok esetben pontatlan lehet.
34
23. ábra: Egy útvonal a térképen ábrázolva. Az utas az Üllői úton az 50-es villamossal a Határ útig, onnan M3-as metróval a Népligetig, onnan pedig 103-as autóbusszal az Etele út/Fehérvári út megállóig közlekedett.
24. ábra: Az útvonal sebesség-idő grafikonja. A grafikonon zöld szín jelöli azt az időszakot, ahol GPS pontosságú volt a mérés, sárga szín pedig azt, ahol csak hálózatalapú helyadatok voltak elérhetők.
25. ábra: A járműpredikció eredménye. Az algoritmus egy valószínűségi pontszámot rendelt a különböző járművekhez, a magasabb pontszám pontosabb találatot jelent. A grafikonok időben egymás alatt helyezkednek el, hogy az események könnyebben összevethetők legyenek. 35
Ezen az tud segíteni, hogy a járművek többsége biztosít olyan információt is, hogy mikor áll meg egy megállóban és nyitja ki az ajtaját. Ahol ez az adat rendelkezésünkre áll, ott biztosak lehetünk, hogy csak ezekben az időpontokban szállhatott fel vagy le az utas. A megállók nevét és az ajtók kinyitásának időpontjait a grafikonon egy M betű jelzi. Ezek mellett az idő során az annotálók visszajelzései alapján további funkciók is belekerültek a felületre, melyek segítségével az adatok nyersen is olvashatók: megtekinthető, hogy egy adott pillanatban milyen predikciót adott a járműfelismerés, valamint hogy egy bizonyos időpont környékén az a jármű milyen adatpontokat szolgáltatott (26. ábra). Ezeket felhasználva az annotációk a különböző id-k ismerete nélkül, kizárólag az annotáló felületen történő kattintgatással elkészíthetők, és adatbázisba illeszthetők.
26. ábra: Járműpredikció egy adott időponthoz (felül), egy adott jármű által küldött pontok részletei (alul)
36
4. Az adatok elemzése A fejezet bemutatja az összegyűjtött adatok elemzésének módját. A 4.1-es alfejezet a földrajzi adatok vizsgálatát végzi el a felhasználó trajektóriáinak a valós idejű járműadatokhoz való illesztésével, a 4.2-es alfejezet a szenzoros adatok elemzését mutatja be, a 4.3-as alfejezet pedig azt ismerteti, hogy a kétféle módszer összevonásával milyen eredmény állítható elő. Végül a 4.4. alfejezet egy példán keresztül bemutatja, hogy milyen adatok érkeznek, és ezekre milyen eredményt ad az elemzés.
4.1. Földrajzi adatok feldolgozása A földrajzi adatok segítségével a felhasználó által megtett útvonal rögzíthető az idő függvényében. A készülék beállításaitól és az útvonal adottságaitól függően az útvonal lehet GPS, WiFi vagy mobil cellainformációk, illetve ezek kombinációja alapján rögzítve. Ezek az összegyűjtött adatsorok (úgynevezett trajektóriák) különféle adatbányászati módszerekkel elemezhetők. [30] A rendszer minden helyadat érkezése esetén közli az alkalmazással a földrajzi szélességi és hosszúsági koordinátákat, GPS alapú helymeghatározás esetén pedig továbbá a GPS szenzor által meghatározott sebesség-, irányszög-, illetve magasságértéket is. Ekkor sokkal sűrűbben kap adatot is a rendszer, körülbelül másodpercenkénti pozíciófrissítés is elérhető.
4.1.1. A földrajzi adatok tárolása A földrajzi adatok egy PostGIS [31] kiegészítővel ellátott PostgreSQL [32] adatbázisban lettek eltárolva. A PostGIS egy kiegészítő modul PostgreSQL adatbázisokhoz, ami térinformatikai (GIS, Geographic Information System) adatok tárolását és feldolgozását teszi könnyebbé. Segítségével gyorsabban és egyszerűbben megoldható a földrajzi adatok kezelése, mint az hagyományos adattárolással elérhető lenne, köszönhetően az általa biztosított indexelési módszereknek, illetve a támogatott földrajzi függvényeknek. A földrajzi adatok három fő részből állnak: a felhasználó készüléke által gyűjtött adatokból, a valós idejű járműadatokból és a statikus menetrendi adatokból. Ez utóbbi kettő tartalma megtalálható a 2.3.3. alfejezetben, a felhasználó által gyűjtött földrajzi adatok pedig az alábbiakat tartalmazzák: –
Dátum és idő, ezredmásodperc pontossággal
–
Koordináta (szélességi és hosszúsági fok)
–
Irányszög (fok északhoz képest)
–
Magasság (tengerszint feletti méter)
–
Sebesség (m/s)
37
–
Helyadat pontossága (becsült méter)
–
Eszköz azonosítója
4.1.2. Az élő járműadatok és a készülék helyadatainak egyeztetése Mivel a valós idejű járműpozíciók és a készüléktől származó adatok sem folyamatosan, hanem szakaszosan érkeznek, és ezek nincsenek szinkronban egymással, ezért szükséges őket illeszteni egymáshoz. Az adatok illesztését többek között lineáris interpolációval lehet megvalósítani – azaz meg lehet becsülni, hogy hol lehetett az objektum egy adott időpillanatban, akkor is, ha nem áll rendelkezésre adat abban az időpontban. Amint a 17. és a 21. ábrákon is látható, a budapesti esetben (és valószínűleg a legtöbb helyen) sokkal sűrűbben rendelkezésre áll a készüléktől származó helyadat, mint az élő járműhelyadat, ezért a felhasználói helyadatok mentén érdemes interpolálni, mivel így pontosabban illesztést kapunk. Ekkor az interpolációs hiba nagy eséllyel elhanyagolható lesz GPS-es adatok esetén: ha másodpercenként érkezek adatok, akkor a hiba 50 km/h-s sebességnél is maximum 13 m körül lehet – ekkora sebességnél viszont nem túl valószínűek a hirtelen irányváltások, tehát nagy valószínűséggel elhanyagolható az interpolációs hiba a GPS-es mérés pontatlanságához képest.
27. ábra: Egy 20 perces példa útvonal a rögzített helyadatokra. Az útvonal délről, a Móricz Zsigmond körtérről indul, innen a Halász utcáig a 1401-es pályaszámú 41es villamossal, utána pedig a Szilágyi Dezső térig (a villamos útvonalához közel) gyalog lett megtéve. A hiányzó adatok a GPS műholdak elérhetetlenségéből adódnak.
38
28. ábra: Az összes jármű helyadata a rögzítés 20 perces időablakában. A színek az adat időpontját jelzik a 20 perces időablakon belül.
29. ábra: Az 1401-es pályaszámú villamos (amin a felhasználó utazott) által küldött helyadatpontok a rögzítés ideje alatt
39
Az interpoláció segítségével ki lehet számolni, hogy hol tartózkodott a felhasználó a helyadatai alapján a járműpozíció érkezésének időpontjában. Ennek technikai megvalósításához a készülék által kiadott adatokat először útvonalakká kellett konvertálni. Ezek paraméterezhető hosszú (jelen példában 3 perces) visszamenőleges útvonalszakaszok minden adatponthoz (3 perc alatt általában 6-9 pont érkezik a járműtől, ezek alapján már viszonylag pontosan meghatározható az, hogy merre halad a jármű). A járműpozíciók érkezésének időpontjaiban a felhasználó pozícióját meghatározva ki lehet számolni a felhasználó és a jármű távolságát. Itt fontos, hogy a két rendszer által használt időpont szinkronban legyen. Ennek érdekében be lett vezetve egy automatikus időszinkronizálás az adatgyűjtő mobilalkalmazásba, ami rendszeres időközönként ellenőrzi a telefon és a szerver idejének eltérését (bővebben a 3.2.5. alfejezetben). A tapasztalatok alapján viszont a budapesti Futár rendszer esetében néha előfordultak 1-2 másodperces pontatlanságok a járművek órabeállításaiban, így ez néhány 10 méteres eltérést tud okozni. Az algoritmus a felhasználó útvonalának pontjaihoz megkeresi az összes, a közelben levő jármű utolsó 3 percben vett adatát, és hogy akkor hol tartózkodott a jármű.
30. ábra: Egy kiválasztott pont és az azelőtt legfeljebb 3 perccel érkező összes járműadat
40
Az összes ilyen ponthoz kiszámolja, hogy az adat érkezésének időpontjában hol volt a felhasználó. Ezek alapján kiszámítja azt, hogy átlagosan milyen távolságra volt egymástól a jármű és a felhasználó. A 31. ábrán láthatók ezek az értékek a 1446-os pályaszámú 49-es villamossal összevetve (az adatgyűjtő nem ezen a járművön utazott).
31. ábra: Az 1446-os pályaszámú villamos helyadatai (kékkel) és a felhasználó adatai (pirossal). Az ábrán látható, hogy az egymáshoz tartozó adatok (zöld vonallal összekötve) viszonylag messze vannak egymástól. A felhasználó nem ezen a járművön utazott. 7. táblázat: Az adatpontok távolsága helytelen becslés során Időpont 2014-10-14 20:18:08+02 2014-10-14 20:18:39+02 2014-10-14 20:18:57+02 2014-10-14 20:19:17+02 2014-10-14 20:19:27+02 2014-10-14 20:19:59+02 2014-10-14 20:20:30+02 2014-10-14 20:20:41+02
Távolság 82,6 m 82,8 m 103,4 m 213,6 m 179,0 m 23,8 m 102,1 m 118,0 m
Az adatokból többféle mérőszámot is számol az algoritmus: egy hagyományos átlagot, egy, a későbbi időpontokat nagyobb súllyal figyelembe vevő súlyozott átlagot a jármű kiválasztására, valamint egy négyzetes átlagot az adatok pontosságának meghatározására. 41
Ezen adatok átlaga 113,2 m, súlyozott átlaga 112,2 m, és látszik, hogy vannak sokkal távolabbi adatok is (a négyzetes átlag értéke 126,0 m), így megállapítható, hogy valószínűleg nem ezzel utazott a felhasználó. A 32. ábrán láthatók az értékek a ténylegesen a felhasználó által igénybe vett 1401-es pályaszámú 41-es villamossal összevetve.
32. ábra: A ténylegesen használt járat adatai (kékkel) és a felhasználó adatai (pirossal). Itt már közelebb vannak az adatok egymáshoz (zöld vonallal jelölve). 8. táblázat: Az adatpontok távolsága helyes becslés esetén Időpont 2014-10-14 20:17:59+02 2014-10-14 20:18:32+02 2014-10-14 20:18:51+02 2014-10-14 20:19:04+02 2014-10-14 20:19:36+02 2014-10-14 20:19:46+02 2014-10-14 20:20:19+02 2014-10-14 20:20:26+02
Távolság 37,1 m 35,1 m 51,7 m 63,6 m 46,2 m 11,5 m 45,6 m 42,0 m
Ezen adatok már sokkal kisebbek, az átlaguk 41,6 m, súlyozott átlaguk 42,3 m, a négyzetes átlag pedig 43,9 m. Az eltérések egyrészt valószínűleg a jármű és a mobiltelefon órájának pár másodperces eltéréséből adódik (a felhasználó helyadatai alapján a jármű a legnagyobb eltérés helyén 30 km/h-s sebesség körül haladt, ekkor ez egy kb. 8 mp-es eltérésnek felel meg), másrészt 42
a felhasználó sem mindig a jármű elejében utazik, ahol általában a jármű helymeghatározó modulja található. (A példában bemutatott villamos 27 m hosszú.) Az összes járműre kiszámolva ezeket az adatokat a 3 perces időablak alatt, a következő járműveket számolta legközelebbinek az algoritmus (a távolságok átlagának sorrendjében): 9. táblázat: Az egyes járművek átlagos távolsága a becslés során Pályaszám/rendszám
Típus
Viszonylat
1401 1446 BPO-576 1400 FJX-212 FJX-211
villamos villamos autóbusz villamos autóbusz autóbusz
41 49 107 19 86 133
Átlagos távolság 42 m 112 m 176 m 308 m 389 m 450 m
Adatpontok száma 8 8 8 8 4 8
… Mivel az összes többi jármű adatát összevetve ez volt a legpontosabb adat, ezért az algoritmus (helyesen) ezt a villamost választotta. Ezt az algoritmus az útvonal teljes hosszára megvizsgálva a 33. ábrán látható eredményt adta.
33. ábra: A jármű meghatározásának eredménye. Bal oldalon az szerepel, hogy eltalálta-e a járművet (zöld, ha igen, piros, ha nem), jobb oldalon pedig az, hogy mekkora biztonsággal (négyzetes eltéréssel) tette ezt meg (zöld a legbiztosabb, piros a legkevésbé biztos). 43
4.1.3. Valós idejű működés A fentiekben leírt módszer kauzális, azaz csak múltbeli adatokat használ fel, és nem nézi, hogy a jövőben hol lesz a jármű vagy a felhasználó. Ezért mobilinternetes kapcsolat mellett (azaz a járművek helyadatainak ismeretében) a leírt módszerrel az is megvalósítható, hogy a telefon valós időben, pontosan tudja, hogy a felhasználó éppen melyik járművön utazik. Ez megoldható például úgy, hogy a készülék a korábbi helyadatait egy szolgáltatásnak feltölti, és az a historikus járműadatokat használva meghatározza a felhasználó által használt járművet, ugyanúgy, mint ahogyan azt utólag tenné. A módszer alkalmazásakor azonban fontos figyelni arra, hogy van egy néhány másodperces késés a járműpozíciók keletkezésének ideje és azok online elérhetővé válásának ideje között. Ennek megvalósításáról az 5.2.2. alfejezet ír majd részletesebben.
4.1.4. A módszer paraméterezése és teljesítőképessége Az algoritmus számára paraméterként megadható, hogy milyen messzire tekintsen vissza időben a járműdetekció során (az előző fejezetben található példák a 3 perces előtörténetet mutatták be). Tóth Dániel vizsgálta, hogy ezen paraméter mely értékére milyen eredményt nyújt az algoritmus. [33] Arra a megállapításra jutott, hogy 60, illetve 90 másodperces időtartamra visszamenőlegesen, a súlyozott átlagos metrikát figyelembe véve a legpontosabb a járműmeghatározás a vizsgált referencia trajektóriahalmazon. Vizsgálatának eredményei, valamint az adatelemzések áttekintése és a felhasználók visszajelzései alapján kétféle hibalehetőség tipikus. Egyrészt hosszú intervallum (pl. 3 perc) választásakor az állapotváltozások környékén nehezen ismeri fel az új helyzetet (felszállás után nem ismeri fel a járművet, leszállás vagy átszállás után pedig továbbra is a régi járművet becsli). Másrészt rövid intervallum (1 perc) választásakor a kevés mérési pont miatt néha hibásan másik járműre tehet (például megállóban beérkezik mögénk egy másik jármű is, miközben a busz hátuljában utazunk). Emiatt a későbbi prototípus információs rendszerben a valós idejű járműmeghatározáshoz használt módszer két különböző paraméterezésű futását ötvözi az algoritmusnak. Egyrészt ad egy „biztos” járműfelismerést a 3 perces algoritmus használatával, másrészt, ha ez nem ad elég jó (50 méternél kisebb súlyozott távolságú) eredményt, akkor ad egy „lehetséges” járműfelismerést az 1 perces algoritmus használatával (itt szintén 50 méternél kisebb súlyozott távolságot vár el, ha ez sem sikeres, akkor úgy dönt, hogy nem utazunk járművön). Ezen módszer használatával az algoritmus hamarabb eltalálja felszállás és leszállás után a helyzetet, de nem téved gyakran utazás közben sem. Hátránya, hogy az 1 perces algoritmus használata miatt hajlamos akkor is „lehetséges” járművet jelezni, amikor nem utazunk, csak a megállóban várakozunk vagy sétálunk, viszont ez kevésbé problémás a felhasználási eseteket tekintve. Ennek megoldására a 4.3-as alfejezet mutat majd lehetőségeket a szenzoradat alapú tevékenységfelismerés használatával.
44
4.1.5. Továbbfejlesztési lehetőségek A használt módszerhez szükség van arra, hogy a jármű valós idejű koordinátái elérhetők legyenek, azaz (budapesti felhasználás esetén) legyen a járművön Futár egység, ami közli az élő helyadatokat. Ez jelenleg, 2015 decemberében a metrók, a HÉV-ek, illetve a 4-es és a 6-os villamosok kivételével minden járműre teljesül, utóbbiak felszerelése a rendszerrel a közeljövőben várható. [34] A valós idejű adatok hiányában lehetőség van a statikus menetrendi adatokhoz illeszteni az adatokat. Ez, mivel a hiányzó járművek Budapesten mind jellegzetes útvonalon közlekednek, viszonylag alacsony párhuzamosítottsággal, a vonal meghatározására alkalmas lehet, viszont például a 4-es és a 6-os villamost a nagyrészt azonos útvonaluk miatt nem tudná megkülönböztetni, amennyiben a járművek nem menetrend szerint közlekednek. A fejezetben leírt módszer továbbfejleszthető, mivel rendelkezésre állnak egyéb adatok is. Ilyen például az, hogy a jármű sebessége, valamint a felhasználó sebessége is kiszámolható két adott pont között, és ezek egyezősége abban az esetben is tud módosítani a valószínűségen, amikor például a jármű és a felhasználó készülékének órái nincsenek szinkronban. Másik lehetőség a várakozási pontok, és ezáltal a megállók megkeresésére a tartózkodási pontok (stay point) meghatározása, amire vannak ismert algoritmusok ([35], [36]). Amennyiben tudjuk, hogy egy utas várakozott egy ideig egy adott ponton, majd egy jármű odaérkezett, ott szintén megállt, és utána együtt haladtak tovább, akkor feltételezhetjük, hogy ott szállt fel az utas. Emellett a jelenlegi várakozási helyszín felismerése hasznos tud lenni az információs rendszer számára is a közeli indulások kijelzésekor. Az adatgyűjtést a mobil cellaadatokra és a WiFi adatokra kiterjesztve további lehetőségek nyílnak meg a helymeghatározásra akkor is, amikor nincsen jó GPS vétel (például metróban vagy alagútban, illetve ha energiatakarékosság miatt a felhasználó letiltotta a GPS alapú helymeghatározást). Ezen adatok összegyűjtése nem vesz igénybe extra energiát, mivel a készüléknek a működéshez amúgy is szüksége van a cellaadatokra, a közeli WiFi adókat pedig Android 4.3-tól kezdve megfelelő hardver esetén a rendszer automatikusan szkenneli helymeghatározási célból a WiFi kapcsolat kikapcsolt állapotában is. Ezen adatok feldolgozásához más megközelítésre van szükség, mint amit a fejezet bemutatott, mivel ekkor nem ismerjük a felhasználó pontos pozícióját – egy-egy cellához több száz méteres terület is tartozhat, főleg kevésbé lakott területeken. Különösen problémás lehet ez a metróban: itt bizonyos helyeken egyetlen antenna fut végig az alagútban a szokásos irányított adók helyett, így azonos cellához tartoznak hosszú szakaszok is. Az androidos készülékek egy része elérhetővé teszi a környező mobil cellák adatait és azok erősségét is, ezekkel a meghatározás pontosítható, de nem minden típusú eszköz képes ezekhez hozzáférni. WiFi adatokból szintén a környező adók 45
egyedi azonosítója és a jel erőssége érhető el adatként. Ebben az esetben figyelni kell arra, hogy bizonyos adók (például vonatokon, autóbuszokban találhatók, mobil hotspotok) helyet változtathatnak, ezeket fel kell tudni ismerni és nem felhasználni helymeghatározásra, valamint arra is, hogy a különböző szolgáltatónál található telefonok, valamint különböző technológiát (2G, 3G, LTE) használó készülékek más és más cellákat láthatnak. Amikor ilyen adatokat akarnak felhasználni útvonal-meghatározásra a szakirodalomban, akkor általában bizonyos szekvenciákat próbálnak felismerni, ami az adott útvonalhoz tartozik. [24][25] Ezen módszer ebben az esetben is használható lenne: mivel előállíthatók rögzített útvonalak, ahol ismert, hogy melyik járművet használta az utas, illetve közben a készüléke milyen tornyokat és WiFi adókat látott, ezekből létre lehet hozni az egyes szekvenciákat különböző szolgáltatókhoz és készülékekhez. Metró esetében is alkalmazható ez a megoldás: mivel a megállók között eltelt idők ekkor viszonylag pontosan számolhatók, ezért az éppen bejárt megállószakasz is meghatározható.
4.2. Szenzoradatok elemzése Az előző fejezetben ismertetett helyadatok mellett a mobil készülékek szenzoradatokat is biztosítanak. Ezek jellegzetes mintákat tartalmaznak, így adatbányászati algoritmusok segítségével fel lehet dolgozni őket. A fejezet célja, hogy bemutassa, hogyan lehet a kísérleti mérésadatgyűjtő rendszer segítségével összegyűjtött és különféle módszerekkel felcímkézett szenzoradatok alapján a felhasználó tevékenységét később meghatározni (klasszifikálni). A klasszifikáció (magyarul osztályozás) lényege, hogy előre ismert, az osztályt is tartalmazó tanulóadatok alapján egy olyan módszert állítsunk elő, melynek segítségével képesek vagyunk újonnan érkező, az osztályt nem tartalmazó adatokra is ezt megbecsülni. Jelen esetben az ismert értékek a telefon által visszaadott szenzoradatok, a kérdéses osztály pedig a felhasználó tevékenysége, ezt szeretnénk megállapítani előre nem ismert adatsorokra is. A tevékenységet többféleképpen is lehet osztályozni, például: –
A felhasználó járművön vagy nem járművön tartózkodik-e
–
A felhasználó milyen járművel utazik (pl. autóbusz, trolibusz, villamos, metró, kerékpár)
–
Nem járművön töltött tevékenység esetén mit csinál (gyaloglás, futás, várakozás, lépcsőzés, liftben vagy mozgólépcsőn utazás stb.)
4.2.1. Korábbi munkák A szenzoros kontextusfelismeréssel kapcsolatban több cikk is született az elmúlt években. Ezeket áttekintve, a működőnek és a jelen rendszerre adaptálhatónak tűnő megoldásokat módosítva alakult ki a jelenlegi módszer. Több korábbi cikk is foglalkozik sportolási tevékenység
46
felismerésével ([37], [38]), illetve közlekedési mód felismeréséről is találni irodalmat ([39], [40], [41]). A munkák többsége ugyanazt az általános folyamatot követi, csak a részletekben és az elő- és utófeldolgozásban van jelentősebb különbség: létrehoz egy tanuló- és teszthalmazt az adatok tanítására és kiértékelésre, majd mindkét halmazból kinyer jellemző adatokat, úgynevezett feature-öket. Mivel a gyűjtött adatok pontszerűek, ezért a feature-ök alatt általában valamilyen aggregálást kell érteni, hogy az egész folyamatra jellemző adatokkal lehessen számolni. A feature-ök kiszámítása után valamilyen tanuló algoritmussal rátanulnak az adatokra, majd pedig a teszthalmazon a megtanult modell alapján kiértékelik a módszer eredményességét.
4.2.2. Adatok kiválogatása és címkézése Az első feladat az adatok kiválogatása: meg kell határozni, hogy mely adatok azok, amelyek egyrészt biztos adatok (pontosan lehet tudni, hogy mi történt rajtuk – ez szükséges ahhoz, hogy biztosan jól tanítsuk, illetve értékeljük ki a tanulás eredményét), másrészt elég változatosak (nem csak egy felhasználó adatai, mivel mindenkinek vannak jellemző szokásai, illetve nem csak egy típusú készüléktől származó adatok, hogy a készülékek jellegzetességeit ki lehessen szűrni). A kiválogatásban segítséget jelentettek a felhasználóknak a mobilalkalmazásban készített kézi annotációi, viszont a hibás, hiányos annotációk miatt nem lehetett csak ezeket figyelembe venni. Egyúttal az annotálás maga is módosítja a szenzoradatokat: ha a felhasználó minden alkalommal előveszi a zsebéből a telefont azért, hogy bejelölje, hogy éppen leszáll a járműről, akkor az algoritmusok rátanulhatnának arra, hogy akkor történik leszállás, amikor a felhasználó maga felé fordítja a képernyőt. A kézi kiválogatás mellett a nagy adatmennyiség miatt automatikus címkézésre is szükség volt: ahol a földrajzi adat alapú járműfelismerés jó minőségű volt, ott ez segíteni tudta a szenzoros tevékenységfelismerés tanuló- és teszthalmazának összeállítását is, mivel a helyinformációk alapján közel teljes biztonsággal tudni lehetett, hogy mikor vagyunk egy adott típusú járművön.
4.2.3. Adatok előkészítése Az adatgyűjtésben vizsgált szenzorok a következők voltak: –
Gyorsulásmérő: a telefon gyorsulását adja meg a telefon relatív koordinátarendszerében, a gravitációs gyorsulás nélkül. Álló helyzetben 0 m/s2.
–
Giroszkóp: a telefon szögsebességét adja meg a telefon relatív koordinátarendszerében. Álló helyzetben 0 rad/s.
–
Gravitációs szenzor: a gravitációs gyorsulás irányát adja meg. Álló helyzetben egy 9,8 m/s2 nagyságú vektor függőlegesen felfele irányban, a telefon koordinátarendszerében.
47
–
Mágneses szenzor: a mágneses tér irányát és nagyságát adja meg µT-ban. A mágneses szenzort
korábbi
munkák
is
eredményesen
használták
helymeghatározásra
fémszerkezetes épületekben [42], ennek analógiájára érdemesnek tűnt kipróbálni, hogy fémszerkezetes járművek esetében is hasznos információkat lehet-e kapni a segítségével.
34. ábra: Gyorsulásmérő szenzor függőleges irányú komponensének adatai. A vízszintes tengelyen az idő, a függőleges tengelyen pedig a gyorsulás mértéke látható. A készülékektől érkező szenzoradatok egy adatsorként érkeznek, amely tartalmazza többek között a szenzor típusát, a küldő készülék azonosítóját, a mérés dátumát, valamint a mért adatokat (a vizsgált szenzorok esetében egységesen 3 érték). Ezekből az adatokból számolhatók különböző származtatott adatok is: –
A gravitációs vektor irányából és a gyorsulás irányából számolható a telefon fel-le irányú és oldalirányú gyorsulásvektora is. Ez több jelentéssel rendelkezhet, mint a készülék irányától függő gyorsulásvektor.
–
Kiszámolható az egyes vektorok hossza is, szintén azért, hogy a készülék állásától függetlenné váljanak a mért értékek.
Ezeket az adatokat ahhoz, hogy összefüggéseket lehessen közöttük keresni, pivotálni kell, azaz össze kell vonni az azonos időponthoz tartozó, különböző típusú adatokat. A szenzoradatok időben általában változnak, sokszor valamilyen periodikus módon. Ezért egy időpillanatban vett szenzorértékekből nem lehet hatékony következtetéseket levonni, szükséges valamilyen módon időben hosszabb tartományon vizsgálni az adatokat. Ez egy csúszó időablakkal lett megoldva, amelynek minden egyes lépésére ki lett számolva több különböző időés frekvenciatartománybeli aggregáló függvény értéke is.
4.2.4. Feature kinyerés Az adatok elemzéséhez az adatsorból ki kell nyernünk jellemző információkat, úgynevezett feature-öket, ezek segítségével határozható meg a felhasználó tevékenysége. A témával foglalkozó korábbi cikkek (elsősorban [43], illetve [41]) megismerése és a számításigények mérlegelése után az alábbi feature-ök kerültek felhasználásra: 48
–
Maximum: A maximális érték periodikus értékek esetén meghatározza, hogy mi a hullám maximális értéke (37. ábra).
–
Átlag: Az átlagos szenzorérték megmutatja, hogy mekkora a vektor átlagos nagysága az adott időablakban (38. ábra).
–
Integrál:
Az
értékek
integrálhatók,
ezáltal
tökéletes
szenzorértékek
esetén
meghatározható lenne a telefon pontos helyzete helymeghatározó rendszerek nélkül is (gyorsulásvektor integráljaként sebesség, annak integráljaként pedig elmozdulás; giroszkóp alapú szögsebesség integráljaként orientáció). Azonban az adatok nem elegendően pontosak, a lehetséges legsűrűbb mintavételezési idő is viszonylag ritka, a hibák pedig az idővel köbösen kumulálódnak, így ezek az integrálok nem használhatók ilyen célra, azonban ennek ellenére egy általános karakterisztika meghatározására jók lehetnek (39. ábra). Amint az az ábrákon látható, az integrálérték és az átlagos szenzorérték nagyon hasonló alakot vett fel. Ennek oka az, hogy a diszkrét adatpontok közötti integrál értéke egy súlyozott átlagként is tekinthető, és mivel a szenzorok mintavételezési ideje megközelítőleg állandó, így hasonló értékeket kapunk. –
Spektrum: A szenzoradatokat Fourier-transzformálva megkapjuk az adatok spektrumát. (35. és 36. ábra)
35. ábra: A mérés diszkrét idejű Fourier-transzformációja (DTFT). Vízszintes tengelyen az idő másodpercben, függőlegesen a különböző frekvenciák, a szín a frekvenciakomponens nagyságát jelzi.
36. ábra: A jel és Fourier-transzformáltja a t=200 s időpontban (gyaloglás). 49
37. ábra: Maximális gyorsulásmérő adatok 5 mp-es időablakon
38. ábra: Gyorsulásmérő adatok átlaga 5 mp-es időablakon
39. ábra: Gyorsulásmérő adatok integrálja 5 mp-es időablakon
50
Ezek a feature-ök többféle szenzoradatra (gyorsulásmérő, giroszkóp, mágneses szenzor), illetve többféle időablakra (1 mp, 5 mp, 10 mp) is ki lettek számolva. Ezen időszakaszok alatt általában már lezajlik és felismerhető a jellemző mozgás, mind például egy lépés (jellemzően 1 Hz körüli frekvencián) vagy egy járműnél a kerék frekvenciája (4-5 Hz körül). [44] Emellett tevékenységfelismeréskor bizonyos esetekben figyelembe lehet venni a földrajzi adatokat is. Itt figyelni kell arra, hogy problémát okozhat az általános megközelítésben, ha földrajzi szélességre és hosszúságra, azaz csak a helyszínekre tanul az algoritmus (bár természetesen ennek is lehet jelentősége – például egy autópályán nagy valószínűséggel járműben utazik a felhasználó, nem pedig kerékpárral vagy gyalog, de ez csak megfelelő lefedettség esetén, illetve az általános módszerrel párhuzamosan használható fel). Emiatt itt elsősorban helyfüggetlen értékekre van szükség – ilyen lehet például a pillanatnyi sebesség vagy a helymeghatározás pontossága. Ez utóbbi például arra lehet hasznos, ha azt szeretnénk megkülönböztetni, hogy a föld alatt (például metróban) vagy a felszínen utazik valaki – metróban a GPS jelek hiánya miatt sokkal kevésbé pontosak az adatok.
4.2.5. Tanulás és az eredmények kiértékelése Az előállított feature-ökre való tanulással előállíthatók olyan modellek, amelyek segítségével tetszőleges adatsorra becsülhető, hogy a megtanult modell alapján mikor mit csinál a felhasználó. A tanulásra és a kiértékelésre használt adathalmazokat fontos volt különválasztani, mivel így lehet csak pontosan mérni, hogy milyen eredménnyel teljesít a módszer. Általános esetben, ha minden példány, amire tanulunk vagy tesztelünk, független egymástól, akkor hatékony és pontos értéket adó módszer a tanulóhalmaz véletlenszerű elemeinek kiválasztása, vagy ennek továbbfejlesztett módja, a cross-validation is. Azonban mivel jelenleg adatsoraink vannak, a közös adatsorból nyert példányok szükségszerűen összefüggenek egymással, ezért ezeket a módszereket használva sokkal jobb (de nem valós) eredményt kapunk, mintha egy másik adatsort használnánk (ami a valóságban előfordul). A tanítás és a kiértékelés a Weka nevű adatbányász szoftverrel történt. [45] Ennek segítségével a legismertebb tanuló algoritmusok könnyedén futtathatók, illetve kiértékelhetők egy megfelelő formába hozott tanuló- és teszthalmazon. A tanítás és a kiértékelés több különböző halmazon, különböző döntésre és algoritmusra végre lett hajtva. Az alábbiakban megtalálható az egyes döntésekre elért eredmények: –
Gyaloglás és járműn utazás elválasztása: A tanulás megvalósításához egy tanuló- és egy teszthalmazt kellett létrehozni, melyek mindegyike egyaránt tartalmaz gyalogosan és járművel megtett szakaszokat is. Mind a tanuló-, mind a teszthalmaz úgy lett előállítva, hogy különböző felhasználók különböző helyen történő utazásait, illetve gyaloglásait 51
tartalmazza, így kiszűrve azt, hogy az algoritmus csak egy bizonyos felhasználó vagy jármű szokásaira, mozgására tanuljon rá. A megtervezett módszerrel jó eredményt sikerült elérni, a független teszthalmazon kiértékelve 97,5%-os pontossággal sikerült osztályoznia az algoritmus számára ismeretlen adatokat. A legjobb eredményeket C4.5 algoritmussal generált döntési fával sikerült elérni. A tanulás során előállított szabályok az oldalirányú és a fel-le irányú gyorsulásmérő adatokat, valamint a giroszkóp adatait és a mágneses szenzor adatait is figyelembe vették. 10. táblázat: A gyaloglás és a járműn utazás elválasztásának eredményei. A táblázat az úgynevezett confusion mátrix: az egyes oszlopokban a predikció eredménye, a sorokban pedig a tényleges érték szerepel. jármű 2110 29
gyaloglás 70 1774
predikció jármű gyaloglás
A döntési fa használatának nagy előnye, hogy a hosszabb idejű tanulás (a fa felépítése) egyszer egy központi szerveren végrehajtható, utána pedig magának a predikciónak az előállítása nagyon egyszerű, mobil készülékeken is hatékonyan végrehajtható. –
Jármű típusának eldöntése: A jármű típusának eldöntésekor szintén szükség volt a független tanuló- és teszthalmaz előállítására. Ehhez ezúttal különböző felhasználóktól, különböző típusú járműveken történt autóbuszos és villamosos rögzítések lettek kiválogatva mindkét halmazba. Ebben az esetben egy Bayes-i háló felépítése bizonyult a leghatékonyabb megoldásnak. Segítségével ismert járműtípusú útvonalakra tanítva az algoritmus számára ismeretlen típusú járművek felismerése átlagosan 86%-os pontossággal volt megvalósítható. Ebben az esetben is hatékonyan megoldható a predikció mobil készüléken is. 11. táblázat: Az autóbuszon és a villamoson történő utazás elválasztásának eredményei. Az egyes oszlopokban a predikció eredménye, a sorokban pedig a tényleges érték szerepel. busz 2924 106
villamos 583 1198
predikció busz villamos
Mivel a modellek futtatásának eredményeként egy idősort kapunk, ezért ezen tovább lehet finomítani utófeldolgozással, akár kauzális (valós idejű tevékenységmeghatározás esetén), akár a jövőbeli adatokat is figyelembe vevő szűréssel (utólagos feldolgozás esetén). Erre egy lehetséges módszer a mozgó ablakos szűrés: ha a predikció azt mondja, hogy a felhasználó folyamatosan egy villamoson van, de utána 10 másodpercig busznak predikálja, majd újra villamosnak, akkor valószínűsíthető, hogy a predikció volt a hibás, és ez javítható.
52
4.2.6. Gyorsítási lehetőségek Természetesen akkor lehet a legjobb eredményt kihozni a tanulásból, ha minden adatot a legjobb minőségben és a lehető legsűrűbben rögzít az adatgyűjtő szoftver, és ezeket továbbítja a feldolgozó eszköznek. Azonban ez a nagy adatmennyiség és a mobil készülékek esetében szükséges energiatakarékosság miatt nem megoldható. Ilyenkor kompromisszumra van szükség: meg kell vizsgálni, hogy milyen értékeket tudunk elhagyni, milyen szenzorok esetében elég kisebb mintavételi frekvencia, pontatlanabb érték, és meg kell nézni, hogy ezek mennyiben módosítják a detekció eredményét. Mivel minden tanítás különböző (akár jelentős mértékben is kicsit különböző tanulóhalmaz esetén), ezért az egyes tanítások után külön-külön meg kell nézni, hogy melyek azok az attribútumok, amik a legkevésbé számítanak az eredmény szempontjából. Aminek nincs jelentős hatása, de mégis sok időbe telik a kiszámítása, az a feature elhagyható, ezáltal kis mértékben rontva a detekciót, de nagy mértékben javítva a futási időt és az energiafogyasztást. Emellett a földrajzi, illetve a szenzoros mintavétel sűrűségének jelentős csökkentésével szintén gyorsabb, energiatakarékosabb adatgyűjtésre van lehetőség.
4.2.7. Végrehajtás a készüléken A feature kinyerések többsége megvalósítható iteratív módon, kis energiaigénnyel egyből a készüléken, ezáltal csökkentve mind a letárolt, mind az átvitt adatmennyiséget. Emellett még a klasszifikálás is végrehajtható hatékonyan (az előzetes tanulás után), ha viszonylag egyszerű algoritmust választunk – az algoritmusok döntő többségénél a predikció nagyságrendekkel gyorsabb a tanulásnál. További optimalizálási lehetőség, hogy nem szükséges folyamatosan végezni a szenzoros adatgyűjtést, mint ahogyan azt eddig az adatok összegyűjtése céljából tette az alkalmazás, hanem elég adott időnként (például félpercenként vagy percenként) ellenőrizni, és egy rövid időtartamból (5-10 másodperces minta) meghatározni az aktuális állapotot.
4.3. Földrajzi és szenzoros adatok együttes alkalmazása A földrajzi adatok segítségével sikerült pontosan meghatározni a felhasználó által használt járművet a felszállási és a leszállási időpontok közvetlen (kb. fél perces) környékének kivételével, a szenzoros adatokkal pedig egy jó becslést lehet mondani a felhasználó tevékenységére, valamint az általa használt jármű típusára. A két módszert összevonva viszont további, a felhasználhatóság szempontjából jelentős eredményeket lehet elérni. A szenzoros adatok által meghatározott állapot segít abban, hogy a földrajzi adatoknál az algoritmus tudja, hogy melyik pontokat kell figyelembe vennie a járműtrajektória keresésénél. Ennek segítségével a felszállás után hamarabb meghatározható a jármű, mivel elég csak a járműre 53
való felszállás után érkező adatpontok segítségével meghatároznia a helyzetet, ezáltal kiszűrve az utazás szempontjából irreleváns pontokat. Hasonlóan, amennyiben a tevékenységfelismerés gyaloglást vagy megállóban várakozást határoz meg, akkor nem fog próbálkozni járműre tenni a felhasználót (ez a hátránya a prototípus rendszerben használt kombinált algoritmus használatának, lásd a 4.1.4-es alfejezetet). Emellett a jármű típusának ellenőrzésére is felhasználható a tevékenységfelismerés: amennyiben a földrajzi algoritmus nehezen tud dönteni például egy villamos és egy busz között, akkor ebben a szenzoros járműtípus-meghatározás segítséget tud nyújtani. A szenzoros adatokkal a leszállás időpontja is pontosabban eldönthető: ha érzékeli a szenzoradatok alapján a rendszer, hogy a felhasználó gyalogol, akkor – ha ez a többi adattal egybevág – feltételezheti, hogy leszállt a járműről. A két módszer fúziójával így sokkal pontosabban meghatározható egyrészt a felhasználó aktuális állapota és az általa használt jármű (ami a navigációhoz lesz hasznos), másrészt pedig a járműre történő leszállás és felszállás időpontja (ami pedig az átszállási idők számítása során lesz fontos információ). A földrajzi adat alapú járműfelismerés emellett segíteni tudja a szenzoros tevékenységfelismerés tanulóhalmazának összeállítását is: mivel tudjuk a helyinformációk alapján, hogy mikor vagyunk egy adott típusú járművön, ezért erre támaszkodva elő lehet állítani nagy példányszámú tanulóhalmazt a szenzoradatok elemzéséhez. Ennek segítségével a későbbi, sok felhasználós üzem esetén lehetőség nyílik arra, hogy a felhasználók utólag ismertté vált földrajzi adatai alapján a kapcsolódó szenzoradatokat automatikusan címkézze, így folyamatosan javítsa, pontosítsa a szenzoros felismerést.
4.4. Az elemzés menete egy példán bemutatva Ez az alfejezet bemutatja egy példán keresztül, hogy milyen adatok érkeznek az okostelefontól, és azokra az egyes elemzések milyen eredményt mondanak. A megvizsgált útvonal három különböző járművet tartalmaz: egy villamost és két autóbuszt. A 40. ábrán látható az utas útvonala, azok a pontok, amelyeket az utazás közben a telefonja rögzített. A készüléken a helybeállításoknál a legjobb minőségű helyadatok voltak engedélyezve, és mivel az utazás végig a felszínen történt, ezért folyamatosan volt GPS vétele az eszköznek.
54
40. ábra: Az okostelefon által rögzített helyadatok, a ténylegesen használt járművekkel színezve. Az utas déli irányból, a Kosztolányi Dezső tér környékétől indul és északnyugat felé halad. Kék: gyaloglás; Piros: Móricz Zsigmond körtér– Clark Ádám tér, 41-es villamos; sárga: Clark Ádám tér–Széll Kálmán tér, 16-os autóbusz; zöld: Széll Kálmán tér–Bölöni György utca / Széher út: 129-es autóbusz.
41. ábra: A helyalapú járműpredikció eredménye 3 perces előtörténettel. A nagyobb értékkel rendelkező adatsorok: piros: 1343-as pályaszámú 41-es villamos; sárga: BPI-387 rendszámú 16-os autóbusz; zöld: MFW-525-ös rendszámú 129-es autóbusz.
42. ábra: Referencia idővonal (felül) és a kombinált járműpredikció eredménye (alul). A színes mezők a járműveken utazást jelentik, a predikció esetében a halványabb színek a „lehetséges” utazásokat, az erősebbek pedig a „biztos” utazásokat. Szürkével az útvonalban nem szereplő járművek vannak jelölve, ezek mind „lehetséges” találatok. 55
43. ábra: A felhasználó sebessége az út során. A grafikonok időben egymás alatt helyezkednek el a könnyebb összevetés céljából.
44. ábra: A készüléktől érkező szenzoradatok. Felül a giroszkóptól érkező szögsebességvektor hossza, alul a gyorsulásmérő szenzortól érkező fel-le irányú gyorsulás értéke látható. A 43. ábra a készülék által biztosított GPS alapú sebességet mutatja az idő függvényében. Ennek segítségével lehetőség van azon helyek meghatározására, ahol –
az utas egy helyben volt (például megállóban várakozás, jármű áll a megállóban vagy a piros lámpánál),
–
az utas járművel haladt (ahol a sebesség magas, ott valószínűleg valamilyen járművön utazott),
–
az utas gyalogolt (ahol a sebesség 4-5 km/h körül van, gyakran megáll, ott valószínűleg gyaloglás történt).
Ha összevetjük ezeket a telefontól érkező szenzoradatokkal (44. ábra), akkor láthatjuk, hogy –
amikor az utas gyalogolt, akkor az intenzíven látszik mind a gyorsulásmérő, mind a giroszkóp adatain, 56
–
amikor az utas járművel utazott, akkor a giroszkóp adatain alig, a gyorsulásmérő adatain viszont észrevehetően láthatunk mozgást (különösen az autóbuszos utazások esetén),
–
várakozás közben, bár jelentős mértékű mozgás ilyenkor nincs, a szenzoradatok mégis jeleznek mozgást, melynek oka például a járműre való fel- és leszállás, illetve a megállóban való sétálás lehet.
A 41. ábra az ehhez tartozó járműpredikciót mutatja be a 3 perces intervallumra, ami a 4.1. alfejezetben bemutatott elemzésből származó eredmény. A 42. ábrán pedig látszik a referencia idősáv (a tényleges utazások hogyan történtek), illetve a kombinált (3 és 1 perces) járműfelismerés eredménye. Itt látszik, hogy az algoritmus alapvetően helyesen eltalálta azt a három járművet, amivel a felhasználó tényleg utazott. Pontatlanságok az egyes útvonalak elején és végén fordulnak elő leggyakrabban. Ezek okai a következők lehetnek. –
Nehéz pontosan meghatározni a felszállás pillanatát kizárólag hely alapján: nem dönthető el könnyen, hogy a felhasználó a megállóban áll-e, vagy pedig már felszállt a járműre.
–
A harmadik járműre való felszálláskor viszont (a jármű a végállomáson várta az indulási idejét) a közelbe érkezés után, még az indulás előtt nagy biztonsággal meg tudta mondani a járművet.
–
Leszállás után az első és a harmadik esetben, mivel a járművek hamar továbbhaladtak, viszonylag gyorsan lecsökkent a valószínűség (az első járműről leszállva azonban, mivel az utas arra haladt tovább, amerre később utolérte a villamos, újra (bizonytalanként) megjelent a jármű.
–
A második jármű viszont a végállomásán maradt, és az utas is itt várt a következő járműre, ezért a pontszám sokkal lassabban csökkent.
–
Amikor az algoritmus biztosra mondja, hogy a felhasználó valamelyik járművön van, akkor az általában tényleg úgy van. Bizonytalan találatokat viszont gyakrabban ad ez a módszer, de azokat is szinte csak akkor, amikor nem járművön utazunk.
Ezeket az eltéréseket a szenzoradatok elemzésével, valamint a jármű ajtónyitásának ismeretében (M betűvel jelölve a 41. ábrán) ki lehet következtetni, és – ahogyan azt a 4.3. alfejezet is kifejti – a két elemzés összevonásával valóban pontosabban meg lehet határozni, hogy mikor történt a felés leszállás az egyes járművekre.
57
5. Információs rendszer Ez a fejezet bemutatja, hogy a jármű és a tevékenység felismerésének segítségével milyen hasznos funkciókat lehet megvalósítani (5.1. alfejezet), illetve bemutatja ezek megvalósításának tervét, illetve részleges implementációját. Jelenleg egy néhány használót támogató prototípus információs rendszer működik, ami alkalmas a különböző funkciók kipróbálására és tesztelésére (5.2. alfejezet). Ennek tapasztalatai alapján kerül bemutatásra egy sokkal több felhasználót kiszolgálni képes, optimalizált éles információs rendszer, ahol azonban egy-egy funkció vagy módosítás megvalósítása több erőfeszítést és erőforrást igényel (5.3. alfejezet).
5.1. Felhasználási esetek Az információs rendszer által támogatandó funkciókat két nagy csoportra bonthatók. Ezek egyrészt az utasok számára hasznos funkciók, amik az alkalmazást használót közvetlenül segítik (például abban, hogy megfelelő útvonaltervet mutat számára), másrészt a közlekedési társaság számára információt biztosító funkciók (például a gyakori átszállási helyzetek kiszűrése). Ez utóbbiak, bár közvetlenül a felhasználót nem segítik, de segítségükkel közvetett módon egy jobban használható, olcsóbban üzemeltethető és így olcsóbban igénybe vehető tömegközlekedési hálózat alakítható ki.
5.1.1. Utasok számára nyújtott információk A rendszer segítségével megvalósíthatók a jelenleg létező okostelefonos alkalmazások által biztosított funkciók (például utazástervezés, menetrend egy adott megállóból). Ezen felül azonban, mivel a rendszer azt is tudhatja, hogy melyik felhasználó hol vagy melyik járművön tartózkodik, további funkciókat is tud biztosítani. Aktuális járműről átszállási lehetőségek Az, hogy a felhasználó melyik járművön utazik, felhasználható arra, hogy olyan átszállási lehetőségeket kínáljunk fel neki, amiket várhatóan el tud érni. Mivel az alkalmazás tudja, hogy a felhasználó melyik járaton utazik, ezért ennek ismeretében tudja, hogy mikor fog egy adott megállóba érkezni és onnan milyen másik járművekre tud átszállni. Átszállási idő becslése A felhasználók pontos viselkedési információinak egyik legnagyobb haszna, amire a leírt módszer megoldást ad, az az, hogy meghatározható az, hogy mettől meddig utaztak az utasok egy adott járművel, mikor szálltak fel rá és szálltak le róla. Ezáltal kiszámolható, hogy mennyi idő alatt ér át az utas az egyik megállóból a másikba, valamint hogy melyek azok a járművek, amiket elérhet, és melyek azok, amelyeket már nem.
58
A gyűjtött adatokból kinyerhető egy közös eloszlás, amely alapján egy szokásos, a felhasználók többségére jellemző átszállási idő számolható. Ez a módszer az útvonaltervezők által jelenleg használt távolság alapú becslésnél pontosabb átszállási időket adna. Személyre szabott átszállási idő becslése Az egyéni átszállási idők között jelentős eltérések lehetnek: van, akinek a szokásosnál rövidebb, van, akinek hosszabb időre van szüksége egy átszálláshoz. Az előző pontban meghatározott átszállási időt nem csak általánosságban lehet kiszámítani, hanem meghatározható személyre szabottan is: ha a felhasználó lassabban vagy gyorsabban szokott átszállni az átlagos utasnál, akkor ennek megfelelően ajánlhat számára olyan átszállási lehetőségeket a szolgáltatás, amik a felhasználó átszállási sebességéhez igazodnak. Így lehet fiatalabbak esetében rövidebb átszállási idővel, idősebbeknek pedig például az akadálymentes közlekedéshez szükséges átszállási idővel számolni. Az előző pontban kiszámolt eloszlások esetében meghatározhatjuk, hogy a jellemző átszállási időtartamok elején vagy a végén teljesít-e általában a felhasználó, és ez alapján mondhatunk számára várható, személyre szabott átszállási időt. Útvonaltervezés személyre szabott átszállási idővel A pontos, személyre szabott átszállási idő, valamint a járműadatokból számított statisztikák ismeretében (például abból, hogy egy adott jármű rendszeresen késik) pontosabb útvonaltervezés biztosítható, mint amit a jelenlegi szolgáltatások nyújtanak. Navigáció személyre szabott átszállási idővel, élő járműadatok alapján A két pont között történő útvonaltervezésen kívül navigációt is lehet biztosítani, azaz a felhasználó aktuális helyzetéből kiindulva (például valamelyik járművön utazik) lehet (az útvonaltervezéshez hasonlóan személyre szabott) útvonalat javasolni. Az útvonaltervezéshez képest a navigáció három ponton jelent eltérést: –
Mivel az alkalmazás tudja, hogy a felhasználó aktuálisan melyik járaton utazik vagy melyik megállóban várakozik, ezért ennek ismeretében tud a felhasználónak az éppen aktuális helyzetéből mint kiindulási helyzetből útvonalat javasolni.
–
Navigációnál jellemzően az élő járműadatokat is lehet használni, ellentétben az útvonaltervezéssel, ami az esetek többségében csak menetrendi, illetve historikus adatokat tud figyelembe venni.
–
Emellett mivel folyamatosan ismeri a felhasználó helyzetét, valós időben tud figyelmeztetni és javaslatot tenni a következő teendőkre is (úgynevezett „turn-by-turn” navigáció, azaz például szól az alkalmazás, hogy az utas szálljon le a következő megállóban).
59
Navigáció rendkívüli események esetén Rendkívüli események, például metró- vagy villamospótlás esetén fontos, hogy a navigáció is a megváltozott helyzethez igazodjon. Ez az élő járműadatok és a többi felhasználó mozgásának ismeretében megvalósítható, a rendszer képes lehet felismerni, hogy valami probléma vagy változás történt, és ennek megfelelően tudná módosítani a javasolt útvonalat. Szokásokhoz igazodó javaslatok A gyűjtött adatok segítségével lehetőség van arra, hogy fel lehessen ismerni a felhasználó szokásait, és ezek alapján lehessen neki útvonaltervezést ajánlani, még mielőtt ő külön megmondaná, hogy hova szeretne menni. A szolgáltatás fel tudja ismerni, hogy a felhasználó mikor szokott munkába, egyetemre indulni hétköznapokon, mikor szokott hazaindulni onnan, hova szokott menni hetente barátokkal találkozni stb. (Hasonló szolgáltatást már nyújt a Google is a Google Now alkalmazás segítségével.) Járművek indulási és érkezési időpontjainak pontosabb becslése A közlekedési vállalatok élő járműadatainak ismeretében lehet statisztikai becslést adni arra, hogy általában mikor érkezik és indul a jármű a megállóból. Ez pontosítható a felhasználói adatok segítségével is, mivel azok gyakrabban érhetők el (1-2 másodpercenként), mint jelenleg a rendszer által ismert pozíciók (20-30 másodpercenként). Azonban a vállalatok rendszerének módosításával, az adatok sűrűbb közlésével az lehetne pontosabb, mivel minden járműről lenne pontos információ, míg felhasználói adatok csak azokról a járművekről érhetők el, ahol valaki olyan utazik, aki használja az alkalmazást. Ez felhasználható az útvonaltervezések javítására: ha tudjuk, hogy melyik busz szokott késve, melyik pedig korábban megérkezni egy megállóba, akkor lehetőség van olyan átszállások szerepeltetésére is az útvonaltervezésben, ami a statikus menetrend alapján elérhetetlennek tűnik; illetve ha egy járat rendszeresen késik, akkor a rendszer nem fog erről a járatról rövid átszállási idős átszállást javasolni egy általában pontosan közlekedő járműre.
5.1.2. Közlekedési vállalatok számára nyújtott információk A rendszerben ismert adatokat, azon túl, hogy segítségükkel a felhasználóknak lehet hasznos, személyre szabott információkat nyújtani, a közlekedési társaság is fel tudná használni. Az alfejezet az alábbiakban ezekre ismertet ötleteket. Pontosabb menetrend készítésének lehetősége A közlekedési vállalatok számára az előző alfejezetben ismertetett járműstatisztikák segítséget tudnak nyújtani abban, hogy a menetrendet dinamikusabban tudják módosítani: például lehet tudni, hogy ha reggel a dugók miatt mindig késni szoktak a buszok, akkor lehet módosítani a meghirdetett menetrendet is ennek megfelelően.
60
Utasszámlálás és utazási szokások vizsgálata A közlekedési vállalatok számára nagyon fontos információ az, hogy az utasaik merre közlekednek, a járataik mennyire kihasználtak. A szolgáltatók rendszeresen végeznek utasszámlálást, ami kiegészíthető lehet a szolgáltatás által biztosított információkkal. A jelenlegi utasszámlálások általában csak azt tartalmazzák, hogy hányan szállnak fel, illetve le a járművekről az adott megállókban, illetve hogy hányan utaznak a járműveken. Emellett egy még kisebb halmazon kérdőíves módszerrel is vizsgálják, hogy honnan hova közlekednek az emberek a városban, aminek segítségével egy úgynevezett célforgalmi mátrixot (más néven O-D vagy Origin-Destination mátrixot) hoznak létre. A szolgáltatás segítségével az utasszámlálás folyamatossá, pontosabbá és sokkal olcsóbbá tehető. Meghatározható nem csak az, hogy ki hol szállt fel, illetve le, hanem az is, hogy pontosan honnan hová közlekedtek az utasok. Így a megállók elhelyezkedése optimalizálható a kisebb gyaloglási távolság érdekében. Emellett az átszállási helyszínek és időpontok ismeretében azt is lehet tudni, hogy hol milyen járműre szálltak át az emberek. Ennek segítségével például meghatározható, hogy mely járatoknak lenne érdemes átszállási szempontból bevárni egymást, vagy hol kellene a megállókat közelebb helyezni egymáshoz. Ezen információk alapján a vállalatok könnyebben tudják optimalizálni a járatok közlekedését, ezáltal is javítva a szolgáltatás minőségét és növelni az utasok elégedettségét. Az utazási szokások vizsgálatánál figyelni kell a demográfiai eloszlásra: jelenleg a fiatalok körében gyakoribb az okostelefonhasználat, így pusztán felszorozva az értékeket a fiatalok által használt járatokon (például iskolák, sportközpontok környékén, éjszakai buszokon) felül, az idősebbek által gyakrabban használt járatokon, illetve időpontokon (például egészségügyi intézmények környékén) alul mérheti a tényleges értékeket. Ez valós utasszámlálásokkal, illetve kérdőívezéssel pontosítható. Ennél sokkal pontosabb utasszámlálásra tud lehetőséget biztosítani egy megfelelő elektronikus jegyrendszer és az abból származó utazási információk használata. A Budapesten bevezetni tervezett RIGO rendszer [46] a járművek többségén várhatóan csak a felszállásokat, illetve (viszonylag jó hatékonysággal) az átszállásokat fogja tudni észlelni, a leszállás helyét és időpontját nem. Emellett a bérlettel utazók a járatok többségén (a nem elsőajtós felszíni viszonylatokon) ebből is kimaradnak. [47]
5.1.3. A funkciók megvalósításához szükséges adatok Az előbbiekben felsorolt funkciók jellemezhetők az alapján is, hogy milyen adatok szükségesek a megvalósításukhoz. Ezt mutatja be a 12. táblázat egyrészt a meglévő alkalmazások, másrészt pedig a jelen információs rendszer által megoldható, az utas számára, illetve a közlekedési társaság számára hasznos funkciók szempontjából. 61
12. táblázat: Az egyes funkciók megvalósításához szükséges adatok. A zárójeles értékek a közvetve vagy nem feltétlenül szükséges adatokat jelölik. Funkció
Egyén
Mindenki Járművek Egyén Mindenki Járművek aktuális pozíciója korábbi pozíciói
Meglévő alkalmazások és szolgáltatások funkciói Hagyományos menetrend Hagyományos útvonaltervezés Élő menetrend Élő útvonaltervezés Közeli indulások
-
-
-
-
-
-
-
-
-
-
-
-
igen
-
igen igen igen
-
-
-
igen
-
igen
-
-
-
-
-
-
-
igen
-
-
-
-
igen
igen
-
-
-
-
igen
igen
(igen)
igen
-
igen
igen
igen
(igen)
igen
igen
igen
(igen)
(igen)
(igen)
-
-
-
-
igen
igen
Utas számára hasznos funkciók Aktuális járműről átszállási lehetőségek Átszállási idő becslés Személyre szabott átszállási idő Személyre szabott útvonaltervezés Személyre szabott navigáció Navigáció rendkívüli esemény esetén Indulási és érkezési időpontok becslése
Közlekedési társaság számára hasznos funkciók Menetrend pontosítása Utasszámlálás
-
-
-
-
igen
igen
-
-
-
-
igen
igen
5.1.4. Működési feltételek Ez az alfejezet bemutatja, hogy milyen feltételek határozhatják meg, hogy hol működik az információs rendszer. Területi feltételek A szolgáltatás tervezésénél szempont, hogy könnyen megoldható legyen, hogy tetszőleges városban működhessen, ahol a közlekedési szolgáltató rendelkezésre bocsátja a szükséges információkat. A dolgozat az eddigi példáiban Budapestet mutatta be, illetve az implementálásra került prototípus rendszer is itt működik a széles körű technikai lehetőségek elérhetősége miatt. Ezek
62
azonban tetszőleges másik városban is működhetnének, ahol a szükséges adatok rendelkezésre állnak. Ezek az alábbiak: –
Menetrend elektronikus formában: ez szerencsére manapság sok helyen elérhető, bár nem minden szolgáltató biztosítja ezeket szabványos formában. A prototípus rendszer jelenleg a GTFS adatformátumot kezeli, ami jelenleg is a világ sok száz városa esetén szabadon elérhető. [48] Magyarországon egyelőre csak a BKK szolgáltat hivatalosan ilyen adatokat, a többi szolgáltató esetén (pl. MÁV, Volánok) más formátumokból lehetne ezeket az adatokat beszerezni, azonban várhatón ezek is egységesítve lesznek a jövőben.
–
Valós idejű járműpozíciók: a jelenlegi járatmeghatározásnak szüksége van arra, hogy tudja, melyik jármű pontosan hol található. Ez – amennyiben van a városban valamilyen élő pozícióközlés a járművekről – az adatforrás megfelelő adaptálását teszi szükségessé. Ennek hiányában szükség lehet más módszerek használatára a használt viszonylat meghatározásához. Ez hozzávetőlegesen megtehető pusztán a menetrendi adatok ismeretében is, viszont a párhuzamosan közlekedő járatok ebben az esetben gondot okozhatnak a felismerésnél. Ez például a navigációnál gondot jelenthet, ha az alkalmazás nem tudja eldönteni, hogy a helyes járaton van-e a felhasználó, vagy pedig a vele párhuzamos, de később elágazó másik járaton. Ebben az esetben a menetrend ismerete segíthet, azonban késések esetén ez nem ad megbízható eredményt.
–
Valós idejű menetrend: a rendszer jelenlegi megvalósítása mellett a valós idejű járműpozíciók mellett szükség van a valós idejű megállóból történő indulási adatokra is, azonban ez a későbbiekben a járműpozíciókból is kikövetkeztethetővé válhat a legtöbb esetben.
Emellett vannak sajátosságai minden városnak, amikre egy idő után rá tudnak tanulni az algoritmusok, ezáltal pontosítva a tevékenységmeghatározást. Ilyenek például a használt járművek típusai (minden járműtípusnak különböző jellegzetességei vannak, amik például a gyorsulásmérőre tanuláskor előkerülhetnek), vagy például a metrók menetideje: mivel a föld alatt nincsen elérhető GPS pozíció, itt felhasználható lehet a szenzoradatokból érkező gyorsulásmérő adat, ebből az esetek többségében meghatározható a felhasználó haladási iránya a megállótávolságok alapján. (Különösen igaz ez az automata vezetésű metrókra, például a budapesti 4-es metróra: ebben az esetben szinte másodpercre pontosan azonos ideig közlekedik a metrószerelvény két megálló között.) Támogatott platformok A jelenlegi mobil alkalmazás a magyarországi okostelefonos statisztikák eredményének fényében elsődlegesen Android rendszerre készült el. Emellett elkészíthető az iOS és a Windows Phone rendszeren használható változat is. 63
Windows Phone rendszeren, Windows 10 Phone vagy későbbi verzió használata esetén a mobiltelefonok várhatóan képesek lesznek iOS alkalmazások futtatására is (eredetileg Android alkalmazásokra is tervezték ezt megvalósítani a Project Astoria keretében, de ezt 2015 szeptemberében kivették a rendszer preview változatából). [49] Ez lehetővé tenné, hogy ne kelljen külön Windows Phone rendszerre is megírni az alkalmazást.
5.2. Prototípus rendszer A prototípus rendszer abból a célból lett létrehozva, hogy legyen egy olyan rendszer, amin a szolgáltatás funkcióit ki lehet próbálni, és ami a funkcionalitás kidolgozása és további ötletek gyűjtése céljából könnyen és olcsón módosítható. A rendszer a 4. fejezetben leírt elemzéseket használja fel működésének alapjaként, a szerver egy kis teljesítményű, olcsón üzemeltethető gép, a mobil alkalmazás pedig az adatgyűjtő alkalmazással szerzett tapasztalatok segítségével alakult ki. Ez a rendszer nem univerzális (csak Budapesten működik), illetve itt nem követelmény a sok felhasználó kiszolgálása, amolyan béta rendszerként működik a vállalkozó szellemű felhasználók számára. Ők hamarabb kipróbálhatják az új fejlesztéseket, és visszajelzéseikkel, ötleteikkel hozzá tudnak járulni azok jobbá tételéhez. Az elég stabilnak, megbízhatónak ítélt funkciók pedig optimalizált módon átkerülhetnek a prototípus rendszerből az éles rendszerbe is, ahol sokkal hatékonyabban, de kevésbé flexibilisen tud futni, és ki tud szolgálni több felhasználót is. Jelenleg a prototípus rendszerben a járműfelismerés, a közeli indulások megjelenítése, valamint az átszállási lehetőségek listázása került megvalósításra. Az 5.2.1. alfejezet bemutatja a rendszer architektúráját, hogy miként kapcsolódnak egymáshoz a prototípus rendszer moduljai. Az 5.2.2. alfejezet ezután részletesen ismerteti a megvalósult funkciókat, az 5.2.3. alfejezet pedig az ehhez szükséges API specifikációját. Az 5.2.4. alfejezet ismerteti az elkészült mobilalkalmazást, az 5.2.5. pedig azt, hogy hogyan történik az adattárolás a prototípus rendszerben. Végül az 5.2.6. alfejezet összefoglalja a további tervbe vett funkciókat, és azok megvalósításának ötleteit.
5.2.1. Rendszer architektúrája A prototípus információs rendszer két nagy részből áll (45. ábra): a felhasználó által használt mobilalkalmazásból, valamint egy szerverből, ami az adatgyűjtést, illetve a különböző funkciókat tudja végrehajtani. A mobilalkalmazás a mérőrendszerben használt adatgyűjtő alkalmazáshoz hasonlít, de ez ezúttal már nem mint adatgyűjtő, hanem mint a felhasználónak szolgáltatást nyújtó alkalmazás van jelen. Közvetlenül csak a szerverrel van kapcsolatban, illetve az Android rendszer által biztosított helyés szenzorinformációkhoz fér hozzá, a Futár API-hoz, illetve a statikus menetrendhez közvetlenül nem fér hozzá.
64
45. ábra: A prototípus rendszer architektúrája. Piros színnel vannak jelölve a dolgozat keretében elkészített modulok. A szerver moduláris felépítésű: rendelkezik egy adatgyűjtő modullal, ami folyamatosan adatbázisba menti a Futár API-n keresztül érkező jármű- és menetrendi adatokat, valamint a mobil készülékek által feltöltött helyadatokat. Ezekből az adatokból dolgozik (az adatgyűjtő modultól függetlenül) a járműfelismerést végző modul: az adatbázisból veszi a jármű-, illetve felhasználói információkat, amiket közli a mobilalkalmazással az éppen használt járművet. Szintén az adatbázissal, illetve közvetlenül a Futár API-val van kapcsolatban az információs modul, ami a közeli indulásokat, illetve a felhasználó által használt jármű várható megállókba érkezéseit, valamint átszállási adatait közli a mobilalkalmazással. A mobilalkalmazás és a szerver JSON alapon, HTTP kérésekkel kommunikálnak. A kommunikációt jelenleg mindig a kliens kezdeményezi, mivel jelenleg csak olyan funkciókat támogat a rendszer, ahol a kliens aktív közreműködése (pl. új helyadat feltöltése) szükséges az információk változásához, nincs olyan használati eset, ahol a felhasználó értesítése elkerülhetetlen lenne, miközben az alkalmazás nem működik. A rendszer megvalósításakor figyelni kell arra, hogy az képes legyen megfelelő kapacitást nyújtani. A mérésadatgyűjtő rendszer esetében a rendszer megbízhatósága nem volt kritikus szempont (a szolgáltatás kiesése esetén az alkalmazások pár órával később megpróbálták újra feltölteni a gyűjtött adatokat), nem is volt szükség egyszerre sok felhasználó kiszolgálására, viszont nagy adatmennyiséggel kellett dolgozni. Ezért egy saját, szerverként üzemelő számítógéppel költséghatékonyan meg lehetett oldani az adatgyűjtést. Jelen esetben a prototípus rendszer esetében még nincsenek nagy igények, tehát ugyanez a szerver megfelelő ezekre a célokra is, viszont az éles rendszernél ez nem lesz elegendő. 65
5.2.2. Megvalósult funkciók Az alábbi alfejezet bemutatja, hogy milyen funkciókat támogat a dolgozat írásakor a prototípus alkalmazás, és azokat hogyan valósítja meg. A következő (5.2.3.) alfejezet bemutatja az ehhez használt API hívásokat is (jelen fejezet dőlt betűvel hivatkozik rájuk). Helyadatok gyűjtése A prototípus rendszer továbbra is gyűjti a felhasználói helyadatokat, mivel ezekre szüksége van a
szolgáltatás
működéséhez,
valamint
annak
továbbfejlesztéséhez.
Ez
a
kísérleti
mérésadatgyűjtőhöz hasonló módon, annak tapasztalatait felhasználva lett optimalizálva. A helyadatgyűjtésnél a prototípus rendszerben is fontos volt a megbízhatóság: a helyadatok inkább lassabban, de biztosan kerüljenek fel a szerverre. Ezért az alkalmazás a helyadatokat először offline módon tárolja le a készüléken, majd használható internetkapcsolat mellett azokat feltölti a prototípus rendszer szerverére (upload_location). A prototípus rendszer jelenleg szenzoradatokat energiatakarékossági okokból nem gyűjt, azonban az alkalmazás úgy lett kialakítva, hogy ez a későbbiekben könnyen hozzáadható legyen. Járműfelismerés A prototípus rendszerben elkészült a járműfelismerést valós időben támogató modul. Ez nagyrészt megegyezik a 4.1. fejezetben bemutatott verzióval (annak is a 4.1.4-es alfejezetében bemutatott, kombinált 3 és 1 perces megoldással). Amin módosítani kellett a bemutatott változathoz képest, az az, hogy az algoritmus mindig az aktuális járműt próbálja felismerni (ne pedig historikus adatokon dolgozzon), és mindezt gyorsan, valós időben tegye több felhasználó esetén is. A felhasználói helyadatok feltöltése után a mobilalkalmazás le tudja kérni egy URL-t lekérdezve az adott felhasználóra vonatkozó járműpredikciót, ami visszaadja a legvalószínűbben használt járművek listáját (nearby_vehicles). Ez megadja a jármű azonosítóját, valamint annak típusát, illetve az éppen kiszolgált viszonylat és menet adatait, illetve a következő megálló kódját. Jelenleg a prototípus rendszer a korábban említett módon kétféle becslést tud adni: egy „biztos” becslést, ami a hosszú ideje használt járműre tud becsülni, illetve egy bizonytalan becslést, ami közvetlenül a felszállás után tudja jó közelítéssel megbecsülni a használt járművet, viszont olyankor is hajlamos becslést adni, amikor a felhasználó még nem utazik egyik járművel sem, csak megállt a megállóban. Ennek a problémának megoldására lehetnek hasznosak a szenzoradatok a későbbiekben. Közeli megállókból történő indulások Az alkalmazás megmutatja a közeli megállókból történő indulásokat. Ez a szerverre feltöltött utolsó felhasználói pozícióhoz legközelebbi megállócsoportok listájának megjelenítését, valamint
66
valamelyikre rábökve az ezen megállócsoporton belüli megállókból történő indulások közül listázza a következőket. (Képernyőkép a 46. ábra bal oldalán látható.) Ezt jelenleg a szerver úgy teszi meg, hogy egy rendszeresen lementett megállólista segítségével megkeresi a felhasználó utolsó pozíciójához legközelebbi megállócsoportok adatait (kód, megálló neve, távolság). A szerver terhelésének, valamint a mobilalkalmazás által használt adatmennyiség csökkentése érdekében ez külön válaszként kerül el a mobilalkalmazáshoz (nearby_stops), az indulások listája másik kérésen keresztül történik. Az indulások listájának lekéréséhez a mobilalkalmazás a megállócsoport kódját, valamint a felhasználó azonosítóját (a távolságszámításhoz) küldi el. A szerver ekkor a lementett megállólista segítségével lekérdezi az ezen megállócsoporthoz tartozó megállók listáját, majd a Futár API-n keresztül lekéri az ezekből a megállókból induló járműveket, és ezekből csinál egy összesített listát (departures_from_stop). Ez a módszer a prototípus rendszer terhelése mellett jól működik, viszont több felhasználó esetén a sok, a Futár API irányában indított kérés problémákat jelenhet a sávszélesség, valamint a válaszidő szempontjából. Ennek megoldására egyrészt lehet cache-elni a Futár API válaszokat (viszont csak rövid ideig, mivel az indulási idők rendszeresen változnak, így ezt csak sok felhasználó esetén érdemes megtenni), vagy pedig a mobilalkalmazások közvetlenül kérdezhetnek a Futár API-tól. A jelenlegi módszerre megoldás lenne még, ha a Futár API lehetőséget adna egy megállócsoportra vonatkozó lekérdezésre. A későbbiekben ez a funkció pontosabbá tehető, ha a megállócsoportok helyett azt veszi figyelembe a rendszer, hogy mennyi idő átérni abba a megállóba. Erről bővebben majd az 5.2.6. alfejezetben lesz szó. Átszállási lehetőségek Az átszállási lehetőségek listázásához a járműfelismerés eredménye alapján a mobilalkalmazás lekéri az éppen használt jármű megállóit, valamint élő megállási információit a szervertől (menetrend szerinti és valós idejű érkezési és indulási idők, trip_details). Ezt a listát szintén megjeleníti a felhasználónak, aki rábökve egy megállóra tudja elérni egy adott megállóban vett átszállási lehetőségeket (lásd 46. ábra, középen). A megállólista színezve van aszerint, hogy mely megállókat hagyta már el, és melyeket nem még. Az átszállási lehetőségek megjelenítése, azaz a megállóból induló járművek lekérdezése hasonló módon történik, mint a közeli megállókból történő induláskor, azzal a kivétellel, hogy itt nem a felhasználó pozíciójához képesti távolságok kerülnek visszaadásra, hanem attól a megállótól vett távolságok, ahová a jármű érkezni fog (transfers_from_stop).
67
Ezen kívül a mobilalkalmazás kiemeli azt a járműt, amivel a felhasználó érkezik, hogy látszódjon, hogy mi az, amit várhatóan elér, és mi az, amit nem (az alkalmazás kiírja a korábban induló járműveket is, hogy látszódjon, ha esetleg a nem menetrendi közlekedés vagy a csatlakozó jármű késése miatt van esélye még elérni azt a járművet).
5.2.3. API leírás A mobilalkalmazás és a szerver HTTP POST és GET kérések segítségével kommunikál, az adatokat JSON formátumban küldik egymás között. Ez az alfejezet bemutatja, hogy milyen kéréseket lehet jelenleg a prototípus szerver felé indítania a mobilalkalmazásoknak. Adatgyűjtés –
upload_location: A helyadatok feltöltését és mentését végzi.
POST kérés tartalmaként egy JSON-t vár a felhasználói helyadatok listájával
Visszatérési érték: OK vagy FAIL, attól függően, hogy sikerült-e lementenie a szervernek és a készülék törölheti-e a helyadatokat
Adatlekérdezés –
nearby_vehicles(device_id): A járműpredikciós algoritmus által visszaadott, a kérés időpontjában vett azon járművek listája, amelyekre a legvalószínűbb, hogy a felhasználó azokon utazik
device_id: felhasználó eszközazonosítója
Visszatérési érték: a járművek listája valószínűségi sorrendben, alapadataikkal együtt
–
nearby_stops(device_id): Közeli megállók a felhasználóhoz
device_id: felhasználó eszközazonosítója
Visszatérési érték: a közeli megállócsoportok listája, a felhasználótól vett távolságukkal
–
transfers_from_stop(stop_id): Adott kódú megállóból és a vele egy csoportba tartozó megállókból induló járatok a következő egy órában
stop_id: megállókód
Visszatérési érték: a járatok listája (menetrend szerinti és becsült érkezési és indulási idővel, a megálló távolságával az eredeti megállótól, valamint a járat adataival)
–
departures_from_stop(stop_id, device_id): Adott kódú megállóból és a vele egy csoportba tartozó megállókból induló járművek a következő egy órában. A felhasználótól vett távolsággal számol a megállótól való távolság helyett.
stop_id: megállókód
device_id: felhasználó eszközazonosítója 68
Visszatérési érték: a járatok listája (menetrend szerinti és becsült érkezési és indulási idővel, a megálló távolságával a felhasználóhoz képest, valamint a járat adataival)
–
trip_details(trip_id, service_date): Visszaadja az adott trip adatait
trip_id: trip azonosító
service_date: service dátuma
Visszatérési érték: megállások listája a megállóadatokkal, valamint a menetrend szerinti indulási és érkezési időpontokkal
–
vehicle_details(device_id, veh_id): Egyetlen jármű adatai, valamint a rá lefuttatott járműbecslés eredménye
device_id: felhasználó eszközazonosítója
veh_id: járműazonosító (saját)
Visszatérési érték: az adott jármű adatai, valamint a predikciós algoritmus által megadott távolságértékek
Egyéb API hívás –
timesync: Aktuális időbélyeget adja vissza a szerveridő szerint, az időszinkronizáláshoz alkalmazható.
5.2.4. Mobilalkalmazás Az információs rendszer részeként elkészült a prototípus szerverhez kapcsolódó mobilalkalmazás is. Ez azokhoz a funkciókhoz ad támogatást, amelyeket jelenleg a prototípus rendszer támogat: megmutatja a felhasználónak, hogy jelenleg melyik járművön közlekedik, arról a járműről hol mire tud átszállni, valamint hogy milyen megállók találhatók a közelben. Felhasználói felület Az alkalmazás felhasználói felülete úgy lett tervezve, hogy a legrelevánsabb információk folyamatosan, görgetés nélkül láthatók legyenek. Így a jelenleg használt jármű látszik legfelül, és ha van ilyen, akkor közvetlenül alatta látszik a megállólista (mikor melyik megállóba fog odaérni, illetve elindulni onnan). Itt egy megállóra bökve ki lehet bontani azt, és ekkor látszódnak az ottani átszállási lehetőségek, és hogy milyen messze van (légvonalban) a megálló. Ha nem utazik járműn a felhasználó, akkor pedig a közeli megállók listája látszik (ez elérhető utazás közben is lejjebb görgetve), és a megfelelőre bökve meg lehet tekinteni az onnan induló járműveket.
69
46. ábra: A prototípus rendszerhez kapcsolódó alkalmazás felülete. Bal oldalon látható a képernyő megállóban várakozás közben, középen utazás közben, jobb oldalon pedig a beállítások képernyő. A jármű megállásainak listázásakor feltüntetésre kerül, hogy mikor kellene menetrend szerint indulnia, valamint azt is, hogy várhatóan mikor fog indulni. Itt az alkalmazás jelenleg a Futár API által közölt értékekkel számol (ami a menetrendi időkön és az aktuális késésen alapul), ez a későbbiekben valószínűleg pontosítható lesz saját, gépi tanulással támogatott számolással. A járműpredikciónál az alkalmazás 3 kategóriát állapít meg: vagy nem talál járművet, vagy bizonytalan a találat (ezt a járatszám mellett található kék kérdőjel jelzi), vagy pedig biztosnak ítéli azt (ezt pedig egy zöld pipa jelzi, lásd a 46. ábra bal oldalán). Az alkalmazás megjeleníti a másodpercre pontos szerveridőt is, így könnyebb ellenőrizni, hogy vajon a megjelenő jármű elment-e már, vagy még nem. Indíthatóság A prototípus alkalmazás jelenlegi verziója az adatgyűjtőhöz hasonlóan külön be- és kikapcsolandó induláskor, illetve megérkezéskor. Ezen a későbbiekben fontos lenne fejleszteni, mivel jelenleg ez jelenti a használat legnagyobb gátját. Amit az alkalmazás indításával és leállításával kapcsolatban fontos figyelembe venni, hogy egyrészt a hely- és szenzorinformációk gyűjtése és kiértékelése miatt energiát fogyaszt, valamint a szerverrel adatkapcsolatban van, így meríti a felhasználó mobilinternet-keretét. Emellett fontos szempont az adatvédelem: a felhasználók többsége nem szeretné, ha minden mozgását automatikusan elküldené az alkalmazás egy szolgáltatásnak – még ha az anonim módon történik is. 70
Ez egyrészt történhet teljesen automatikusan (ha az alkalmazás észreveszi, hogy mozog a felhasználó, akkor bekapcsolja magát, ha észreveszi, hogy már egy ideje áll, akkor pedig kikapcsolja). Az intelligens indítás és leállítás megvalósítására az Android biztosít egy úgynevezett geofence (magyarul „földrajzi kerítés”) funkciót, aminek az a lényege, hogy a készülék anélkül, hogy az alkalmazás folyamatosan monitorozná a helyadatokat, tud értesítést küldeni az alkalmazásnak, ha a felhasználó elhagyja a korábbi helyét, például elindul otthonról. Emellett a Google Play Services modul biztosít androidos alkalmazásoknak alapvető tevékenységfelismerés modult, ami, bár a dolgozatban tárgyalt célokhoz nem ad elég pontos és gyakori adatot, de az automatikus indításhoz elegendő a pontossága. Ezekkel a módszerekkel jelentősen csökkenthető az akkumulátorhasználat és növelhető a készülék üzemideje, mivel nem kell folyamatosan adatot gyűjteni. A felhasználó mozgását a prototípus alkalmazás jelenleg is képes észlelni (a beállítások menüben ez bekapcsolható), de jelenleg adatvédelmi okokból ekkor is csak egy értesítést jelenít meg, amire bökve bekapcsolható az adatgyűjtés. Másrészt – ha majd az útvonaltervezés funkció működni fog – akkor működőképes megoldás lehet felajánlani a felhasználónak az általa használt fontosabb célpontokat (mint egy érintéssel kiválasztható opciókat, esetleg rátanulva a felhasználó korábbi utazásaira, kedvelt helyeire), és oda útvonalat tervezve mutatja mindig a legcélszerűbb eljutási módot egészen addig, amíg meg nem érkezik (vagy az alkalmazás észre nem veszi, hogy már egy ideje nem mozog). Energiatakarékosság Már a prototípus rendszer mobilalkalmazásánál is szempont volt, hogy az az erőforrásokkal (akkumulátor, adatforgalom) takarékosan bánjon. Ennek érdekében az alkalmazás csak akkor kéri le a járműpredikció és a további információs szolgáltatások eredményeit, ha a képernyő be van kapcsolva, az alkalmazás pedig előtérben van. Listaelemek esetén ekkor is figyel arra, hogy csak a látható elemeket frissítse, a nem megnyitott, illetve a görgetéskor a képernyőn kívülre került elemeket nem frissíti folyamatosan. Az adatforgalom csökkentése érdekében továbbá minden, a szerver által küldött JSON adat tömörítve érkezik a készülékre. Visszajelzési lehetőségek A prototípus alkalmazás fontos része, hogy a felhasználók visszajelezhetnek (akár pozitívan, akár negatívan) arról, hogy a járműpredikció eltalálta-e a használt járművet. Emellett a beállítások képernyőn keresztül (46. ábra jobb oldalán) lehetőség van hibajelentések vagy javaslatok küldésére is. Ezek a hibajelzések e-mailben érkeznek, és a felhasználó a küldése előtt választhat, hogy szeretné-e megosztani az azonosítóját (ez tud segíteni a hibakeresésben), vagy továbbra is anonim szeretne-e maradni.
71
Fejlesztői mód A prototípus alkalmazásban elhelyezésre került egy „fejlesztői mód” funkció, aminek segítségével bekapcsolhatók különböző hibakeresési információk (például járműdetekciónál az, hogy mekkora távolságot számolt a megadott járműhöz képest, vagy az időszinkronizáció esetén az, hogy mekkora időeltérés van a telefon és a szerver órája között). Ezek alapból el vannak rejtve (mivel ez a végfelhasználó számára csak zavaró információ), viszont problémák keresésénél hasznos, ha lehet kérni a felhasználót, hogy küldjön ilyen jellegű információkat. Elérhetőség Az Android rendszerre készült mobilalkalmazás letölthető a Google Play Store-on keresztül Android 4.0 vagy újabb rendszert futtató telefonokra és tabletekre: https://hunyadym.hu/app
5.2.5. Szerveroldali adattárolás és -feldolgozás A prototípus rendszer jelenleg – hasonlóan a kísérleti mérésadatgyűjtőhöz – egy PostgreSQL adatbázisban tárolja az adatokat. Erre elsősorban a PostGIS földrajzi kiegészítője miatt esett a választás, ennek segítségével könnyen lehet földrajzi adatokat tárolni, valamint azokkal számolni, műveleteket végezni. A rendszer minden beérkező adatot (a felhasználók és a járművek helyadatait, a megállók és a menetrend adatait) automatikusan adatbázisba tölt. A prototípus rendszer (a kísérleti rendszerhez hasonlóan) minden adatot megőriz a későbbi kutatások, illetve továbbfejlesztések megkönnyítésének érdekében. Járműadatok A járműadatok jelenleg a Futár API-n keresztül vannak letöltve, 5 másodpercenként. Ez 250 KB és 1,5 MB közötti adatmennyiséget jelent (napszaktól függ, hogy hány jármű fut a városban), ez naponta megközelítőleg 17 GB adatforgalom. Ezekből az adatokból ezután ki kell szűrni azokat a járműinformációkat, amelyek többször is szerepelnek (mivel átlagosan 20 mp-enként frissülnek a járműpozíciók, nagyjából 4-szer szerepel minden járműinformáció), valamint betöltésre kerülnek az adatbázisba, ahol (köszönhetően a JSON helyetti bináris tárolásnak, valamint az ismétlődő információk egyszeri letárolásának) kb. naponta 1 GB tárhelyet foglalnak. A letárolt adatok köre a 2.3.3. alfejezetben van részletesen bemutatva. Ezekben az adatokban gyorsan kell tudni keresni, elsősorban időpont alapján (az alapján alaposan leszűrhető az óriási adatmennyiség). Emiatt mindenképpen szükség lesz egy indexre, a dátum mezőre. Azonban ha az összes járműadatot egy adatbázistáblában szeretnénk tárolni, akkor ez az index nagyon hamar kezelhetetlen méretűre nőne, és egy-egy új adatsor beszúrása nagyon lassúvá válna. Emiatt a prototípus rendszeren (ahol szükséges megőrizni minden adatot) a járműadatok napi bontásban particionálva vannak.
72
Ez azt jelenti, hogy a rendszer naponta új táblát hoz létre az adatoknak, és mindig csak a legfrissebbe helyez el adatot. Így az index mérete maximalizálva lesz, és nem fordulhat elő az, ami a particionálás nélkül gondot okozott, hogy 5 másodpercnyi adat beszúrása a táblába több idő volt, mint 5 másodperc, így feltorlódtak az adatok. A PostgreSQL (mint szinte minden modern adatbázis-kezelő) beépítve támogatja a particionálást, és a lekérdezésekben a dátumra szűrve automatikusan
a
szükséges
partíciót
(adatbázistáblát)
veszi
elő.
Az
automatikus
partíciókészítéshez pedig a pg_partman nevű kiegészítőt használja a prototípus rendszer. [50] Menetrendi adatok A BKK a meghirdetett menetrendet folyamatosan közzéteszi a saját weboldalán GTFS formátumban. [51] Ezek általában 1-3 naponta szoktak frissülni, minden nap éjfél és hajnali 1 között. Ezért a prototípus rendszer minden nap hajnali 1:30-kor letölti a friss menetrendet, és ha az megváltozott, akkor ezt elhelyezi az adatbázisban. A hajnalra ütemezett feladatok jól működnek jelen esetben, mivel egy földrajzi területről vannak a felhasználók: a hajnali időszakban az ezek által okozott extra terhelés az alacsony felhasználói terhelés miatt nem okoz problémát. Az éles rendszernél, ha az több, különböző földrészen elhelyezkedő várost is támogatni fog, akkor ez már nem feltétlenül lesz jó megoldás, mivel az időzónák eltolódása miatt sokkal kevésbé lesznek jól meghatározható völgy- és csúcsidőszakok. A menetrendi adatoknál fontos verziózni a különböző változatait a GTFS adatbázisnak az adatok feltöltésekor, hogy ezek ne keveredjenek egymással. A lekérdezések esetén pedig mindig az adott dátumhoz tartozó legfrissebb változatot kell figyelembe venni. Felhasználói helyadatok A felhasználók pozícióadatit a mobil készülékek küldik fel automatikusan a prototípus szerverre, ahol azok letárolásra kerülnek. Ez ugyanazokat az adatokat jelenti, amiket a kísérleti mérésadatgyűjtő rendszer is letárolt (bővebben a 4.1.1. alfejezetben). Ezek az adatok is automatikusan belekerülnek az adatbázisba. A szükséges tárhely mérete attól is függ, hogy milyen képességei vannak a telefonnak, általában 5-10 MB/aktív óra adatmennyiség gyűlik össze. Ez kis (10-20 fős) felhasználószámnál (amit a prototípus szervernek kell bírnia) nem jelentős mennyiség, viszont az éles szerver tervezésénél már számolni kell vele.
5.2.6. Tervek a következő funkciókra Aktivitásdetekció A szenzoradatok alapján történő aktivitásfelismerésre a 4.2. fejezet egy, szerveroldalon offline működő megoldást mutat be. Ezt a megoldást azonban az adatforgalommal való takarékoskodás
73
miatt fontos lenne kliensoldalon elhelyezni, viszont az is hasznos, ha ezek a későbbiekben feldolgozás és további tanítás céljából (nem valós időben) feljutnának a szerverre. A funkció megvalósítása során fontos odafigyelni arra, hogy a szenzoradatok gyűjtése ne merítse le nagyon gyorsan a mobil készülékeket. Míg az adatgyűjtőnél még nem okozott problémát, a prototípus rendszernél azért már elvárt, később az élő rendszernél pedig rendkívül fontos, hogy az
energiafelhasználás
a
lehető
legalacsonyabb
legyen.
Aktivitásdetekciónál
az
energiafelhasználás több részből áll össze: –
szenzoradatok kiolvasásából: ez egyrészt batch-szerű feldolgozásokkal, másrészt a mintavétel frekvenciájának csökkentésével csökkenthető,
–
az adatok feldolgozásából: minél kevesebb és könnyebb műveletet kell végrehajtanunk, annál kevesebb energiára van szükség,
–
az adatok szerverre való elküldéséből: ez fontos az algoritmus továbbfejlesztésének érdekében, de mivel realtime csak a felismerés eredményére van szükség, nem feltétlenül kell azt mobilinterneten vagy alacsony akkutöltöttség esetén felküldeni, lehet akkor is, amikor töltőn van a készülék és WiFi adatkapcsolatot használ.
Mivel az aktivitásfelismerésnél a tanítás általában jóval bonyolultabb, mint a felismerés, ezért – bár tanítani mindenképpen szerveroldalon érdemes – a felismerést (például egy döntési fa alapján) képesek a mobil eszközök is maguk elvégezni. Egy ilyen esetben oda kell figyelni arra, hogy csak a szükséges adatok kerüljenek feldolgozásra, például ne számoljunk spektrumot, ha az úgysem szól bele a döntésbe. Az aktivitásfelismerés alkalmazásba implementálása után érdemes itt is lehetőséget biztosítani a felhasználói visszajelzésekre, hogy meg lehessen mondani, eltalálta-e a tevékenységet a rendszer. Ennek stabil működése után lesz érdemes a járműdetekcióval összevonni és annak javítására felhasználni. Cellainformációk és WiFi adatok alapján történő helymeghatározás Amikor nincsen elérhető GPS adat, akkor a környező WiFi hozzáférési pontok listájának és erősségének, valamint a mobil cellainformációk használatával van lehetőség tájékozódni. Ez hasznos tud lenni például a metrókban történő helymeghatározáshoz – jelenleg a GPS alapú megoldás a metróban nem tud semmilyen információt adni, az Android rendszer által biztosított hálózatalapú helymeghatározás (ami egyébként ugyanezeket az adatokat használja) pontatlan a funkciók működéséhez. Mivel a tömegközlekedés esetében többet tudunk mondani ezek alapján, mint általános esetben, itt a helymeghatározásban lehetne eredményeket elérni. Bővebben ennek technikai megvalósításról a 4.1.5. alfejezetben volt szó.
74
Átszállási idő becslés Az átszállási idő becslése a járműről való leszállás, valamint az induló jármű megállójába való érkezés időpontjának ismeretében megoldható. Ennek az algoritmusnak nem kell valós időben működnie, ezért fel lehet használni hozzá csak későbbi időpontokban rendelkezésre álló adatokat is. Ehhez az első lépés a megállóban történő várakozások megtalálása. Ez megoldható egyrészt a korábban (4.1.5. alfejezet) már említett stay pointok megkeresésével, másrészt pedig a fentebb részletezett tevékenységfelismerés segítségével is. Ezután meg kell nézni az utazás későbbi részének járműdetekciója alapján, hogy a felhasználó ebből a megállóból melyik járműre szállt fel. Mivel pontosan lehet tudni, hogy melyik megállóban melyik járat áll meg, ezért ezzel sokkal pontosabb tud lenni a megálló meghatározása közeli megállók (akár az út túloldalán, akár egy nagyobb megállóhelyen) esetén, mintha pusztán hely alapján történne. Hasonlóan meg lehet határozni azt is a korábban használt jármű detekciója segítségével, valamint a tevékenység (gyaloglás) felismerésével, hogy melyik megállóban és mikor szállt le a felhasználó. Ennek idejét kivonva a megállóba érkezés időpontjával meg lehet határozni egy időértéket arra az átszállásra. Ezek az időértékek sok különböző felhasználó adatait összegezve egy haranggörbe jelleget tudnak kiadni. Egy bizonyos idő alatt nem lesznek értékek (mert fizikailag lehetetlenség annyi idő alatt odaérni – egy alsó korlát adható akár csak a légvonalbeli távolság és egy maximum sebesség alapján, az ennél kisebb értékek mérési hibák). Ezután az eloszlás kiad egy nagyobb tartományt, amin belül vizsgálható, hogy hol helyezkedik el általában egy adott felhasználó értéke az eloszlást tekintve, és ennek segítségével személyre szabható módon adható a későbbiekben becslés egy olyan átszállási lehetőségnél is, ahol még nem járt az adott felhasználó. Figyelni kell azonban arra is, hogy az eloszlás tartományában lehetnek nagyobb eltérések például a lámpaciklusok miatt is – ebben az esetben viszont a várható átszállási időnél is figyelembe kell venni ezeket. Átszállási lehetőségek esetén séta megengedése Jelenleg az átszállási lehetőségeket csak az ugyanazon megállócsoporthoz tartozó megállókból mutatja az alkalmazás (azaz például a Deák Ferenc téren átszállásnak tekinti az összes többi, a Deák Ferenc téren található megállóból induló járművet). Ez azonban a közeli megállók miatt néha kihagy olyan átszállási lehetőségeket, amiket egyébként gyalog nem lenne nehezebb megtenni, mint máshol pár perc alatt átsétálni egy tér két vége között (egy példa a 47. ábrán látható).
75
47. ábra: Példa olyan átszállási lehetőségre a Deák Ferenc térnél, ahol nem az azonos nevű megállóban érdemes átszállni. Az Óbuda felé haladó 9-es buszról (a térképen piros színnel jelölve) szeretnénk a Gyöngyösi utca felé haladó 105-ös buszra (zöld színnel) átszállni. Ekkor, bár az 1. jelű megállók mind a Deák Ferenc térhez tartoznak, érdemesebb a 2. jelű megállók között átszállni (Szent István Bazilika és Bajcsy-Zsilinszky út), mivel kisebb a gyaloglással megtett távolság. Az átszállási távolságokat az előző pontban ismertetett átszállási idő számolás segítségével ekkor lehetne idő alapon számolni, nem pedig kizárólag az azonos megállócsoportok alapján vizsgálni. Ebben az esetben figyelni kell arra is, hogy mindig csak a legértelmesebb átszállási javaslatokat ajánlja fel az alkalmazás. Például ha egy megállóban leszállva elérünk egy másik buszt 500 m-t gyalogolva az aktuális megállóból, de az utána 2 perccel megáll az 50 méterre levő megállóban is, akkor ne ajánlja fel a messze levő verziót, hiába érnénk el ott is a járművet, csak azt, amelyikhez elég később elindulni. Útvonaltervezés A felhasználók számára az egyik legfontosabb funkció az útvonaltervezés tud lenni: ha el szeretne jutni a városban az egyik pontból a másikba, akkor hogyan tudja ezt a leggyorsabban, a legegyszerűbben vagy a legolcsóbban megtenni. Jelenleg is sok szolgáltatás biztosít útvonaltervezést közösségi közlekedési adatokon (erről bővebben a 2.2. alfejezetben volt szó). Léteznek open source megoldások a tömegközlekedési hálózaton történő utazástervezésre, a legismertebb ilyen az OpenTripPlanner, amin például a BKK Futár rendszerének utazástervezése is alapul. 76
Útvonaltervezésnél a hagyományos megoldás két pont között működik, ezt támogatják általában a különböző szolgáltatások. Azonban ha már valaki elindult valahová, és éppen egy járművön utazik, akkor lehet értelme egy járat és egy másik pont között is útvonalat terveztetni. Ezt jelenleg az alkalmazások nem tudják, így nehézkes olyankor útvonalat tervezni, amikor az ember már elindult az úticélja felé. Ennek megvalósítása nem bonyolult technikai szempontból, ekvivalens tud lenni a használt jármű következő megállójából történő útvonaltervezéssel az ottani odaérkezési idővel számolva, ha biztosítjuk, hogy ugyanazzal a járművel tovább tud utazni (és nem számolunk várakozási időt). Útvonaltervezésnél alapvetően a megérkezési időre, valamint ezen belül a gyaloglások távolságára szokás optimalizálni, és így meghatározni a legjobb változatot. Ennek megoldására léteznek különböző módszerek, gráfalgoritmusok, amik gyorsan tudnak kiterjedt hálózatokon is útvonalat tervezni. Azonban figyelni kell arra is, hogy az algoritmus (bár a fenti célfüggvényt, a megérkezés idejét, illetve a gyaloglások távolságát minimalizálhatja) ne ajánljon fel teljesen értelmetlen útvonalakat. Ilyen látható például a 48. ábrán: tényleg ez lesz a fenti feltételeknek legjobban megfelelő utazás, de egyben elég értelmetlen is, és sokkal nagyobb a kockázata, hogy egy átszállást lekésünk.
48. ábra: Példa felesleges utazás ajánlására a BKK Futár útvonaltervezőjéből. Az utazástervező a 931-es éjszakai busszal tervezett útvonalat a Margit híd, budai hídfőig, ahonnan a Széll Kálmán térig kellett elmennie az utasnak, ahonnan a 956os éjszakai busszal tud továbbutazni. Itt az útvonaltervező a gyaloglás minimalizálása érdekében az utast elküldte kelet felé a 6-os villamossal az Oktogonig (ahol pár méterrel rövidebb az átszállási távolság, mint a többi megállóban), majd onnan szintén 6-os villamossal vissza (a Margit híd, budai hídfőn keresztül) a Széll Kálmán térig. Ez azért történhetett meg, mivel a 956-os busz csak óránként közlekedik, ezért ez a kitérő nem jelent késedelmet a célhoz való megérkezésben. Az extra utazás viszont ebben az esetben kifejezetten értelmetlen, plusz egy vonaljegyébe kerül az utasnak, illetve az átszállásokat is kevésbé biztosan éri el. 77
Navigáció Amellett, hogy a felhasználó útvonaltervet kérhet két pont között, a navigációs funkció abban is segíteni tudja, hogy az aktuális helyzetéből eljusson egy meghatározott pontba, és mindeközben utasításokat adjon a telefon, hogy melyik megállónál szálljon le, illetve melyik járműre szálljon fel. Ennek alapját az előző pontban leírt útvonaltervezés adja. Az éppen aktuális tevékenységet az alapján lehet ajánlani, hogy a járművek pillanatnyi késése, valamint a felhasználó által ténylegesen igénybe vett jármű milyen útvonalat tesz lehetővé. Fontos figyelni arra, hogy ha a navigáció használatával a felhasználó elindult egy irányban, akkor a rendszer ne ajánljon sok különböző módosítást a pillanatnyi helyezet megváltozása miatt. Ez hagyományos autós navigációnál nem jelent problémát, mert ott fixen van egy legrövidebb út, amit csak akkor szükséges újratervezni, ha a felhasználó elhagyta azt; viszont tömegközlekedés esetén előfordulhat, hogy két busz közül egyszer az egyik, másszor a másik halad előbbre és érkezik hamarabb a célponthoz, emiatt egyszer azt javasolja a felhasználónak a rendszer, hogy az egyikre, másszor pedig hogy a másikra szálljon fel. Az viszont kifejezetten fontos, hogy ha az előre tervezett útvonal valami miatt megvalósíthatatlanná válik (például annyit késik a jelenlegi busz, hogy várhatóan lekési az átszállást), akkor történjen újratervezés, és ne az eredeti tervhez ragaszkodjon a navigáció. Útvonalak utólagos ellenőriztetése A prototípus rendszert, mint tesztrendszert használó felhasználókat meg lehetne kérni időről időre, hogy ellenőrizzék a saját utazásaikat, hogy megfelelően értelmezte-e azokat a rendszer. Ez visszajelzést tudna adni arról, hogy mi történt, és könnyen lehetne referencia adathalmazt létrehozni a segítségével, amellyel javítani lehet a későbbiekben az algoritmusok működésén. Ehhez érdemes a felhasználónak egy térképnézetet adni, ahol látja az útvonalat, valamint az alkalmazás által predikált járműveket, tevékenységeket (itt felszállt, eddig utazott ezen a járművön, itt leszállt stb.). Az itt megmutatott predikció célszerűen már egy utófeldolgozott predikció lesz, mivel itt már nincs szükség arra, hogy mindig csak a korábbi eseményeket ismerve, kauzális módon határozzuk meg a tevékenységeket, hanem felhasználhatjuk a későbbi ismereteinket is. Ez hasznos tud lenni, mert például hiába tűnik úgy, hogy beállt egy busz a megállóba, és sokáig közel van hozzá a felhasználó, ha utána a busz tovább megy, a felhasználó meg a megállóban marad, akkor a rendszer biztosan tudni fogja, hogy az utas nem azt a buszt vette igénybe. Ehhez részben hasonló funkciót tud nyújtani a Google Maps Helyelőzmények funkciója, amelyről egy képernyőmentés a 49. ábrán látható.
78
49. ábra: A Google Maps helyelőzmények (location history) funkciója. Az oldalon vissza lehet követni az utazásokat, valamint hogy mikor merre tartózkodott a felhasználó. Jelen példában tömegközlekedéssel (metró és trolibusz) beutazott az egyetemre, itt tartózkodott fél 10 és háromnegyed 6 között, majd utána gyalog és villamossal hazament. Az oldal azonban azt nem tudja megmondani, hogy pontosan milyen járműveket használt az utas. Akadálymentesség Az, hogy egy mobilalkalmazás tudja, hogy melyik járművön utazik a felhasználó, és azon belül is hol tart az utazásában, valamint navigáció közben jelzi, hogy éppen mi a következő teendője, nagy segítség tud lenni a vakok számára. Ebben az esetben azonban külön figyelmet kell szentelni annak, hogy az információk semmiképp ne legyenek félrevezetőek (míg egy látó ember csak legyint arra, ha eltéveszti a buszt, mert látja a kijelzőn, hogy nem azon van, mint amit a járműfelismerés mondott, egy vak ember esetében ez egy erősen megtévesztő információ tud lenni). A látó embereknek is hasznos szolgáltatások mellett lehetőség van arra, hogy külön vakoknak készült funkciók is belekerüljenek az alkalmazásba: például tájékoztatni tud arról, hogy milyen járművek érkeznek éppen a megállóba (akár a jármű típusát is tudja közölni, ami egy gyakorlott tömegközlekedő vak személynek tud segíteni abban, hogy a több bent álló busz közül melyik az, amire ő fel szeretne szállni). A vakok általában valamilyen szövegfelolvasó rendszert használnak az okostelefonokon. Ezek manapság szinte minden mobil operációs rendszernek részei, akadálymentes üzemmódban a gombok nyomogatása helyett gesztusokkal vezérelhetővé válik a telefon. Azonban fontos dolog ezek használatához, hogy az alkalmazást fejlesztőknek fel kell készülniük ezekre az esetekre: meg
79
kell adni például, hogy milyen sorrendben lehessen végignavigálni a gombokon, valamint valamilyen szöveges leírást kell adni például a képi információkról, amit a szövegfelolvasók fel tudnak olvasni.
5.3. Skálázódó, éles működésre alkalmas rendszer Az előző fejezetben bemutatott prototípus rendszer ki tud szolgálni néhány felhasználót, és számukra egy viszonylag könnyen fejleszthető szolgáltatást tud biztosítani. Azonban amennyiben ezt többen akarják használni, akkor ez a rendszer már nem lesz elég, szükséges jelentősen optimalizálni a különböző funkciók működését. Ez az alfejezet bemutatja, hogy mik szükségesek ahhoz, hogy létre lehessen hozni egy „éles” szolgáltatást, ami skálázódó módon képes sok felhasználót kiszolgálni. Ez az alfejezet először áttekinti, hogy milyen követelményeknek kell megfelelnie egy ilyen éles rendszernek, majd ismerteti a felhőszolgáltatásokat, és azt, hogy ezek miképpen lehetnek alkalmasak a követelmények teljesítésére. Ezután ismertet néhány fontosabb optimalizálási szükségletet és megváltoztatandó módszert a prototípus rendszerhez képest a szerver, illetve a mobilalkalmazás szempontjából.
5.3.1. Követelmények Az alábbi pontok összefoglalják, hogy milyen szempontokra kell figyelni az éles rendszer kialakításakor. Sok felhasználó, skálázódás Az éles rendszert szükséges felkészíteni arra, hogy sokkal nagyobb felhasználói bázist ki tudjon szolgálni, megbízhatóan, stabilan működjön, illetve a rajta a felhasználó kérésére azonnal futó algoritmusok (pl. útvonaltervezés, navigáció) és a rendszeresen futó adatlekérések (átszállási idők újrabecslése, statisztikák kiszámítása) számára szükséges folyamatos számítási kapacitás biztosítására. Mivel a rendszer használóinak száma folyamatosan változik, illetve a felhasználók se egyenletesen használják azt (például éjjel jóval kevesebben utaznak, mint reggel csúcsidőben), ezért a szerver terhelése is folyamatosan változni fog. Emiatt szükséges az, hogy egy jól skálázódó architektúrán fusson a szerver, hogy ha kisebb az igény, akkor kevesebb, ha nagyobb, akkor több gép álljon rendelkezésre. Optimalizált Bár manapság szinte korlátlan számítási kapacitást lehet bérelni, ez magas költségekkel is jár. Emiatt fontos, hogy az éles rendszer esetében az egyes funkciók működése optimalizálva legyen. Ekkor kevesebb gép is meg tudja oldani ugyanazt a feladatot, így a bérlési költségek jelentősen csökkenni tudnak. 80
Az optimalizálások viszont nem mindig oldhatók meg ugyanazon biztosított teljesítmény mellett. Ha a minőség kismértékű csökkenése mellett lehetőség van a számításigény, és így a költségek jelentős csökkentésére, akkor lehetséges, hogy ezt érdemes meglépni. Ezt azonban előtte fontos megvizsgálni, erre is alkalmas a prototípus rendszer. Emellett lehetőség van még arra is, hogy a számítások egy részét (például a szenzoradatok előfeldolgozását vagy a tevékenységfelismerést) a mobil készülékekre tudjuk bízni. Ez általános esetben nem szokott jó megoldás lenni (jobban merülnek a készülékek), viszont itt is lehet egy optimális minőség-energiahatékonyság értékű megoldásra, trade-offra törekedni. Több város támogatása A prototípus rendszer egy város (Budapest) támogatására lett felkészítve, emiatt az jelenleg csak a BKK által biztosított információkat tudja kezelni, sok helyen rendszerspecifikus módon működik. Más rendszerek más-más adatokat tudnak biztosítani például a járművekről, megállókról: például a MÁV vonatinfó rendszere azt is megmondja, hogy mekkora sebességgel közlekedik egy vonat (a BKK nem ad ki ilyen információkat a járműveiről), viszont azon információkat, hogy mikor közlekedik egy vonat, teljesen más struktúrában közli. Emiatt érdemes lenne itt egy univerzális formátumban tárolni az adatokat (tehát minden adattagnak van benne helye, bővíthető módon), az adatok beolvasását pedig modulárisan megoldani (új szolgáltatás támogatásánál csak azt kell megírni, hogy hogyan alakítja a szolgáltatás által biztosított adatokat az univerzális formátummá). Rendszeres adatmentés Fontos, hogy a felhasználók által gyűjtött, illetve a tömegközlekedési adatokat folyamatosan tárolja el a szerver, hogy a későbbiekben ezek felhasználhatók legyenek az algoritmusok fejlesztése céljából. Azonban ezekre az adatokra nincs szükség folyamatosan, tehát nem kell őket gyorsan elérhető tárterületen (például adatbázisban vagy memóriában) tárolni, lehet őket tömörítve, egy megbízható, kevésbé hozzáférhető, de olcsóbb tárterületen eltárolni.
5.3.2. Felhőszolgáltatások A felhőszolgáltatások segítségével skálázódó módon lehet különféle erőforrásokhoz (tárhely, számítási kapacitás) hozzáférni, általában az árazásuk ahhoz igazodik, hogy hány és milyen gépet vagy mekkora és milyen minőségű tárhelyet, illetve sávszélességet használ az ember. Emellett segítségükkel földrajzilag szétosztva (így a leállások kockázatát minimalizálva) lehet stabil szolgáltatást biztosítani. Ezen előnyök miatt az éles rendszert érdemes valamely felhőszolgáltatáson futtatni, mivel ez a kezdetekben nem jelent nagy költséget, az igények növekedésével viszont könnyen skálázható.
81
Jelenleg a legnépszerűbb felhőszolgáltatások, amik alkalmasak webes szolgáltatások, és így az éles rendszer futtatására is, az Amazon AWS, a Google Cloud Platform, a Microsoft Azure és a Heroku.
5.3.3. Szerveroldali optimalizálás Az éles rendszer szerveroldalánál fontos különbség a prototípus rendszerrel szemben, hogy az egy felhőszolgáltatáson fog futni. Így ennek megfelelően kell módosítani a prototípus rendszerben használt algoritmusokat is. Adattárolás Adattárolás szempontjából szerveroldali adattárolás esetén fontos szétbontani a folyamatosan szükséges adatokat, valamint a csak archiválásra vagy későbbi feldolgozás számára mentett adatokat. Az előbbieket fontos gyakran elérni, és ezek a kis adatmennyiség miatt a memóriában is tárolhatók (például a járműfelismerés esetén az elmúlt 3 perc járműpozíciói), míg az utóbbiakat elegendő egy lassú tárhelyen tárolni, mivel csak a későbbi offline feldolgozásokhoz lesz rájuk szükség. Felhőszolgáltatások esetén az adatbázisoknál előnyben részesítik a NoSQL megoldásokat, mivel könnyebben skálázhatók, mint a hagyományos relációs adatbázisok (de természetesen ezeket is lehet használni ilyen környezetben is). Az információs szolgáltatás számára szükséges adatok is tárolhatók nem relációs adatbázisban. Amire viszont figyelni kell, hogy a PostgreSQL (elsősorban a PostGIS kiegészítőnek köszönhetően) sok olyan funkciót támogatott, ami az adatfeldolgozásnál hasznos volt, és a NoSQL adatbázisokban nem található meg. Azonban ezek az idő nagy részében az elmúlt rövid időszak adatain futottak, nem pedig a teljes historikus adatmennyiségen (és ha igen, akkor is csak annak egy kis szeletén), így ez nem akadálya egy NoSQL adattárolásra való áttérésnek. Adatfeldolgozás A felhőalapú rendszereknél általában párhuzamosított adatfeldolgozást érdemes végrehajtani, mivel így sok különböző gépen is lehetőség van ezeket egyszerre futtatni. A járműfelismerés algoritmusa könnyen párhuzamosítható, mivel a különböző felhasználók elemzései futhatnak egymástól függetlenül, akár külön gépeken is. Itt érdemes lehet a szükséges járműadatokat memóriában előfeldolgozni, mivel minden felhasználó által kért járműfelismerés ezeket használja. A tevékenységfelismerés is hasonlóan párhuzamosítható, emellett ez még a mobileszközökre is áthelyezhető, mivel nincs szükség külön járműadatokra ehhez, csak az előzetesen megtanult modellre. Természetesen a különböző gépi tanuló algoritmusoknak is van felhőalapú tanulásra szánt változata – ez egy kifejezetten olyan terület, ahol ez lényeges tud lenni. Így a jelenleg egy szálon futó szenzoros tanulóalgoritmusok átalakíthatók felhőalapú tanulássá, aminek segítségével sokkal 82
gyorsabban lehet ezeket sokkal nagyobb (sok felhasználó által összegyűjtött) adathalmazon is végrehajtani. Adatforgalom Az adatforgalom kérdése okozhat még költségeket felhőszolgáltatások esetén: általában a sávszélességet kevésbé korlátozzák, az adatmennyiség viszont egy adott limit elérése után fizetős tud lenni. Emiatt fontos a mobilkészülékekkel való kommunikáció tömörítése és a minimálisra szorítása. A szerver-kliens kommunikáció már a prototípus rendszerben is tömörítve működik, azonban szükség lehet az éles rendszer esetén, hogy például a szenzoradatok nyersen már ne, csak aggregált formában kerüljenek fel a felhőszolgáltatás szerverére.
5.3.4. Mobilalkalmazás változásai Mivel az éles rendszer mobilalkalmazása nagyrészt megegyezik a prototípus rendszer mobilalkalmazásával, ezért érdemes ezt nem külön implementálni, hanem azonos kódbázisra épülve két külön verziót létrehozni. Androidon ez könnyen megvalósítható az úgynevezett „build flavor”-ök használatával, ebben az esetben több különálló Android alkalmazás hozható létre, amelyeknek a forráskódja nagyrészt azonos, de segítségével megoldható, hogy bizonyos moduljait (amik még fejlesztés alatt állnak) csak a prototípus alkalmazás tartalmazza, valamint hogy az egyik alkalmazás a prototípus, a másik pedig az éles szerverhez kapcsolódon. Így a prototípus mobilalkalmazás egyfajta „béta” verziónak is felfogható az éles mobilalkalmazáshoz képest. A mobilalkalmazás szempontjából az energiatakarékosság kérdése továbbra is fontos, ennek részleteiről az 5.2.4. alfejezetben már volt szó.
5.4. További lehetőségek Az alábbi fejezet felsorol további lehetőségeket, amik megvalósíthatók lennének, de azokhoz nem csupán az információs rendszer fejlesztése szükséges, hanem más rendszerek kialakítása vagy fejlesztése is.
5.4.1. Beaconök Az úgynevezett „beaconök” (magyarul esetleg bóják [52]) olyan kisméretű, Bluetooth LE alapú jeladók, amelyeket el lehet helyezni bizonyos helyekre (például buszmegállók, járművek), és a készülékek képesek ezek közelségét érzékelni. Így sokkal pontosabban meg lehet határozni a felhasználó relatív pozícióját például egy megállóhoz képest, illetve érzékelni, ha valaki egy ilyen beaconnel ellátott járművön utazik. A beaconök rendelkeznek egy-egy egyedi azonosítóval, de egyéb adatokat (például megálló kódja, koordinátái; jármű rendszáma) is tartalmazhatnak. [53]
83
5.4.2. Futár API-ban hasznos változtatások A jelenlegi Futár API-val néhány, az információs rendszer által tervezett, illetve megvalósított funkciót nehézkes megoldani (például sok különböző API kérésre van szükség, amit egy közös válaszként is visszaadhatna a szerver). Ezen API-n módosítva ezek hatékonyabbak lehetnének, így az információs rendszer, de a Futár API szerverei számára is sávszélességet és processzoridőt megtakarítva.
5.4.3. Gyakoribb járműhelyadatok A Futár API jelenleg 20-30 másodpercenként közöl adatot egy járműről. Ennek sűrűbbé tételével egyrészt a járműfelismerés is pontosítható lenne, másrészt statisztikákat is könnyebben lehetne számolni. Emellett a járműhelyadatok időbélyegét is pontosabbá lehetne tenni: mivel minden Futár egység GPS alapján veszi a pontos időt, ezt lehetne a helymeghatározáshoz amúgy is szükséges GPS időhöz igazítani. (A jelenlegi tapasztalatok alapján néhány másodperces eltérés van a különböző Futár egységek által jelzett időpontok között, ez pontatlanságot okoz a járműdetekciónál.)
5.4.4. Egységes API több szolgáltatónak A különböző tömegközlekedési szolgáltatók adatainak integrálásához hasznos lenne, ha ezek egységes formátumban tudnának adatokat biztosítani az információs rendszer számára. GTFS alapú menetrendet már sok vállalat biztosít világszerte (Magyarországon viszont egyelőre még csak a BKK), az élő járműadatok viszont szinte minden szolgáltatónál más-más formátumban érhetők (vagy nem érhetők) el. Itt megoldás lenne egyrészt például a GTFS-RT (fejlesztők számára is elérhető) használata, vagy akár más népszerű API formátumoké, mint például a BKK által is támogatott OneBusAway API-ja.
84
6. Összefoglalás A dolgozat azzal foglalkozott, hogy hogyan lehet egy olyan közösségi közlekedési információs rendszert létrehozni, ami a bemutatott járműfelismerés és tevékenységfelismerés segítségével különböző, korábban nem megvalósítható funkciókat tud biztosítani. A jelenleg használatban levő rendszerek és megoldások áttekintése után a dolgozat: –
ismertette a kísérleti mérőrendszert, melynek segítségével nagy mennyiségű hely- és szenzoradatot sikerült gyűjteni a későbbi adatelemzések céljára,
–
bemutatta a gyűjtött adatokat és azok jellegét,
–
elemezte az adatokat: a bemutatott módszer hosszabb úton pontos járműfelismerést tett lehetővé a felhasználó telefonjának helyadatai alapján, tevékenységmeghatározást biztosított a mobil szenzoradatok alapján, majd pedig bemutatta azt a módszert, amely a két információ összevonásával lehetővé teszi a járműfelismerés navigációhoz, illetve az átszállási idő meghatározásához szükséges javítását,
–
felvázolta, hogy milyen funkciókat lehet ezen információk ismeretében nyújtani, mind az utas, mind pedig a közlekedési vállalat számára,
–
bemutatta a prototípus információs rendszerben megvalósított és annak androidos alkalmazásában működő funkciókat: a járműfelismerést, a közeli indulások listázását, valamint az átszállási lehetőségek megjelenítését,
–
ismertette a további, a prototípus rendszerben megvalósítandó funkciókat, illetve azok elkészítésének vázlatos tervét,
–
leírta, hogy mire van szükség ahhoz, hogy ezek egy éles, skálázódó rendszerben is működhessenek.
A dolgozatban leírt járműmeghatározás és a kapcsolódó kutatási munka 2015 áprilisában bemutatásra került az MIT által szervett NetMob konferencián is. [54]
85
Köszönetnyilvánítás Szeretnék köszönetet mondani elsősorban konzulensemnek, Dr. Lukács Gergelynek, valamint korábbi konzulensemnek, Dr. Oláh Andrásnak az általuk adott szakmai és emberi támogatásért. Köszönöm továbbá az adatgyűjtő barátaimnak, ismerőseimnek segítségüket, akik utazásaik rögzítésével adatokat biztosítottak az elemzésekhez és lehetővé tették a dolgozat megszületését, közülük is leginkább Kakasi Dávidnak, Simon Péternek, Hunyady Mihálynak és Kozák Csabának, akiktől a legtöbb visszajelzést kaptam. Külön köszönöm Pálffy András, Kovács Lóránt és Huszár Domonkos hasznos tanácsait a dolgozat tartalmával kapcsolatban.
86
Irodalomjegyzék [1]
IVU, “Next Generation Passenger Information System in London.” [Online]. Available: http://www.ivu.com/press/press-releases/article/next-generation-passenger-informationsystem-in-london.html.
[2]
IVU, “IVU.realtime for BVG.” [Online]. Available: http://www.ivu.com/references/europe/ivurealtime-for-bvg.html.
[3]
IVU, “IVU.rail for DB REGIO.” [Online]. Available: http://www.ivu.com/fileadmin/ivu/pdf/casestudies/IVU_cs_dbregio_EN.pdf.
[4]
BKK, “BKK Futár.” [Online]. Available: http://bkk.hu/futar.
[5]
BKK, “BKK Futár Utazástervező.” [Online]. Available: http://futar.bkk.hu/.
[6]
Kisalföld Volán, “Kisalföld Volán Zrt. online győri utastájékoztatási felülete.” [Online]. Available: http://webgyor.kisalfoldvolan.hu/.
[7]
IHO, “Vonatkövetés valós időben,” 02-Aug-2011. [Online]. Available: http://iho.hu/hir/vonatkovetes-valos-idoben.
[8]
MÁV, “Vonatinfó – a mindent tudó belföldi vasúti utazástervező!” [Online]. Available: http://www.mavcsoport.hu/mav-start/belfoldi-utazas/vonatinfo-mindent-tudo-belfoldivasuti-utazastervezo.
[9]
MÁV, “MÁV-Start Vonatinfó.” [Online]. Available: http://vonatinfo.mav-start.hu/.
[10] MÁV, “Vonatinfó,” Google Play. [Online]. Available: https://play.google.com/store/apps/details?id=hu.mavszk.vonatinfo. [11] BKK, “Budapesti közösségi közlekedési menetrend a Google térképén,” Jun-2011. [Online]. Available: http://www.bkk.hu/2011/06/budapesti-kozossegi-kozlekedesimenetrend-a-google-terkepen/. [12] Google, Inc., “Google Maps.” [Online]. Available: https://www.google.com/maps/. [13] Nemzeti Média- és Hírközlési Hatóság, “Távközlési szolgáltatások a háztartásokban, 2014.” NMHH, 10-Apr-2015. [14] StatCounter, “Top Mobile Operating Systems in Hungary.” [Online]. Available: http://gs.statcounter.com/#mobile_os-HU-monthly-201011-201511. [15] Google, Inc., “Google Térkép,” Google Play. [Online]. Available: https://play.google.com/store/apps/details?id=com.google.android.apps.maps. [16] BKK, “BKK Futár,” Google Play. [Online]. Available: https://play.google.com/store/apps/details?id=hu.webvalto.bkkfutar. [17] BKK, “BKK Info,” Google Play. [Online]. Available: https://play.google.com/store/apps/details?id=hu.innostart.bkk. [18] T. Szincsák, “Budapesti menetrend,” Google Play. [Online]. Available: https://play.google.com/store/apps/details?id=hu.donmade.menetrend.budapest. 87
[19] iMind Kft., “BPMenetrend,” Google Play. [Online]. Available: https://play.google.com/store/apps/details?id=hu.bpmenetrend.activity. [20] Ponte.hu, “Smart City Budapest,” Google Play. [Online]. Available: https://play.google.com/store/apps/details?id=hu.ponte.mobile.smartcity. [21] Moovit, “Moovit,” Google Play. [Online]. Available: https://play.google.com/store/apps/details?id=com.tranzmate. [22] B. McClendon, “Google Lat Long: New features ahead: Google Maps and Waze apps better than ever,” 20-Aug-2013. [Online]. Available: http://googlelatlong.blogspot.hu/2013/08/new-features-ahead-google-maps-and-waze.html. [23] M. Berlingerio, F. Calabrese, G. D. Lorenzo, R. Nair, F. Pinelli, and M. L. Sbodio, “AllAboard: A System for Exploring Urban Mobility and Optimizing Public Transport Using Cellphone Data,” in Machine Learning and Knowledge Discovery in Databases, H. Blockeel, K. Kersting, S. Nijssen, and F. Železný, Eds. Springer Berlin Heidelberg, 2013, pp. 663–666. [24] N. K. Hiroki Ishizuka, “Detecting Train Commuters using CDRs and GIS information,” presented at the NetMob 2015, 2015. [25] M. von Mörner, “Application of Floating Phone Data (FPD) in Germany,” in NetMob 2015 Book of Abstracts, Boston, 2015, vol. Posters, pp. 74–75. [26] BKK, “A BKK Zrt üzletszabályzata.” 07-Oct-2014. [27] Google, Inc., “What is GTFS?,” 12-Jan-2012. [Online]. Available: https://developers.google.com/transit/gtfs/. [28] Google, Inc., “GTFS-realtime,” 26-Jul-2012. [Online]. Available: https://developers.google.com/transit/gtfs-realtime/. [29] M. Kiss, “BKK Futár Utazástervező API.” [Online]. Available: http://docs.bkkfutar.apiary.io/. [30] C. Renso, S. Spaccapietra, and E. Zimányi, Mobility Data. Cambridge University Press, 2013. [31] Refractions Research, “PostGIS.” [Online]. Available: http://www.postgis.org/. [32] The PostgreSQL Global Development Group, “PostgreSQL.” [Online]. Available: http://www.postgresql.org/. [33] D. Tóth, “Trajektória adatok elemzése,” Budapest, 2015, pp. 20–25. [34] BKK, “Átadtuk a FUTÁR rendszert,” 01-Oct-2014. [Online]. Available: http://www.bkk.hu/2014/10/atadtuk-a-futar-rendszert/. [35] Y. Zheng, L. Zhang, X. Xie, and W.-Y. Ma, “Mining Interesting Locations and Travel Sequences from GPS Trajectories,” in Proceedings of the 18th International Conference on World Wide Web, New York, NY, USA, 2009, pp. 791–800.
88
[36] R. Hariharan and K. Toyama, “Project Lachesis: Parsing and Modeling Location Histories,” in Geographic Information Science, M. J. Egenhofer, C. Freksa, and H. J. Miller, Eds. Springer Berlin Heidelberg, 2004, pp. 106–124. [37] S. Dernbach, B. Das, N. C. Krishnan, B. L. Thomas, and D. J. Cook, “Simple and Complex Activity Recognition Through Smart Phones,” presented at the 8th International Conference on Intelligent Environments (IE), Guanajuato, Mexico, 2012, pp. 214–221. [38] T. Bernecker, F. Graf, H.-P. Kriegel, C. Moennig, D. Dill, and C. Tuermer, “Activity Recognition on 3D Accelerometer Data (Technical Report),” 2012. [39] B. Nham, K. Siangliulue, and S. Yeung, “Predicting Mode of Transport from iPhone Accelerometer Data.” Stanford, 2008. [40] Y. Zheng, Y. Chen, Q. Li, X. Xie, and W.-Y. Ma, “Understanding Transportation Modes Based on GPS Data for Web Applications,” ACM Trans. Web, vol. 4, no. 1, Jan. 2010. [41] S. Hemminki, P. Nurmi, and S. Tarkoma, “Accelerometer-Based Transportation Mode Detection on Smartphones,” presented at the 11th ACM Conference on Embedded Networked Sensor Systems, New York, NY, USA, 2013, pp. 13:1–13:14. [42] J. Chung, M. Donahoe, C. Schmandt, I.-J. Kim, P. Razavai, and M. Wiseman, “Indoor Location Sensing Using Geo-magnetism,” in Proceedings of the 9th International Conference on Mobile Systems, Applications, and Services, New York, NY, USA, 2011, pp. 141–154. [43] D. Figo, P. C. Diniz, D. R. Ferreira, and J. M. P. Cardoso, “Preprocessing Techniques for Context Recognition from Accelerometer Data,” Pers. Ubiquitous Comput., vol. 14, no. 7, pp. 645–662, 2010. [44] I. Partzsch, “Positioning in real-time public transport navigation: Comparison of vehiclebased and smartphone-generated acceleration data to determine motion states of passengers,” in Networks for Mobility 2012. 6th International Symposium. Proceedings, Stuttgart, 2012, p. 10. [45] M. Hall, E. Frank, G. Holmes, B. Pfahringer, P. Reutemann, and I. H. Witten, “The WEKA data mining software,” ACM SIGKDD Explor. Newsl., vol. 11, no. 1, p. 10, Nov. 2009. [46] BKK, “BKK RIGO elektronikus jegyrendszer.” [Online]. Available: http://rigo.bkk.hu/. [47] BKK, “Elektronikus jegyrendszer.” . [48] “Transitfeeds.com.” [Online]. Available: http://transitfeeds.com/feeds. [49] “Microsoft’s Project Astoria and Android app emulation not happening anytime soon,” Windows Central. [Online]. Available: http://www.windowscentral.com/microsoftsproject-astoria-delayed. [50] “keithf4/pg_partman,” GitHub. [Online]. Available: https://github.com/keithf4/pg_partman. 89
[51] BKK, “Fejlesztőknek.” [Online]. Available: http://www.bkk.hu/tomegkozlekedes/fejlesztoknek/. [52] C. Gálffy, “Eddystone: új Bluetooth-bója szabvány indul,” HWSW. [Online]. Available: http://www.hwsw.hu/hirek/54259/google-beacon-boja-eddystone-bluetooth-le.html. [53] “Beacons,” Google Developers. [Online]. Available: https://developers.google.com/beacons/. [54] M. Hunyady, G. Lukács, and A. Oláh, “Vehicle-relative passenger positioning,” in NetMob 2015 Book of Abstracts, Boston, 2015, vol. Posters, pp. 60–61.
90
