Szenzoradat alapú okostelefonos szolgáltatás közösségi közlekedési algoritmusok pontosításához és személyre szabásához

Szenzoradat alapú okostelefonos szolgáltatás közösségi közlekedési algoritmusok pontosításához és személyre szabásához Szerző: Hunyady Márton Mérnökinformatikus MSc, 1. évfolyam Témavezetők: Dr. Lukács Gergely egyetemi docens, PPKE-ITK Dr. Oláh András egyetemi docens, PPKE-ITK Pázmány Péter Katolikus Egyetem Információs Technológiai és Bionikai Kar Budapest, 2014.

Absztrakt A mai okostelefonok többsége rendelkezik beépített helymeghatározó képességgel, illetve többféle szenzor (pl. gyorsulásmérő, giroszkóp) is megtalálható bennük. Ezek adatainak összegyűjtésével lehetőség nyílik arra, hogy meghatározzuk a felhasználó viselkedését, mozgását, és ennek segítségével jobb, személyre szabott szolgáltatást tudjunk nyújtani mind a felhasználónak, mind pedig a szolgáltatást használó teljes közösségnek, amit egyébként csak hosszas és nehézkes mérések segítségével lehetne biztosítani. A dolgozat azt vizsgálja, hogy hogyan lehet ezeket az adatokat összegyűjteni, ezt az adatmennyiséget feldolgozni, majd pedig egy specifikus témakörben, a nagyvárosi közösségi közlekedés útvonaltervezésében és navigációjában felhasználni, ezáltal javítani és személyre szabni a jelenleg létező szolgáltatásokat. A leírt módszer ezt a felhasználó járatokhoz kapcsolódó relatív pozíciójának, állapotának (pl. utazás, átszállás, várakozás) pontosabb meghatározásával teszi meg, amit egyrészt a valós idejű járatinformációk és a felhasználó helyadatainak összevetésével határoz meg, másrészt az eredmények pontosításának érdekében az okostelefon szenzorainak segítségével tevékenységfelismerést hajt végre. 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 és a megállóba érkezés időpontja meghatározható. A felhasználó pontos fel- és leszállási, valamint a következő jármű megállójába érkezésének ideje alapján lehetőség nyílik a felhasználók átlagos, illetve személyre szabott átszállási idejének meghatározására. Ez egy olyan adat, amit jelenleg egy publikus szolgáltatás sem használ fel a népszerű útvonaltervezők általában túlbecsülik az átszállásra szánt időt, ami így a gyakorlatban elérhetőnél és a bemutatott módszer által meghatározottnál lassabb eljutást és pontatlanabb tervezést tesz lehetővé a felhasználók számára. Emellett a dolgozatban leírt módszer biztosítja a valós idejű tömegközlekedési navigáció pontos megvalósításához szükséges adatokat is. A dolgozatban bemutatott teljesítőképesség-analízis arra is rámutat, hogy az elérhető pontosság, a valós idejű működés, valamint az erőforrások (pl. energiafogyasztás, adatforgalom) mobil platformokra jellemző limitáltságból fakadó követelmények egyidejűleg nem optimalizálhatóak, ezért a megvalósítás során mérnöki trade-offra van szükség. 2

Tartalom Absztrakt... 2 1. Bevezetés és motiváció... 5 2. Közösségi közlekedési rendszerek... 7 2.1. Forgalomirányító és utastájékoztató rendszerek... 7 2.1.1. Budapest forgalomirányítási és utastájékoztatási rendszere... 7 2.1.2. A Kisalföld Volán forgalomirányítási és utastájékoztatási rendszere... 8 2.1.3. A MÁV forgalomirányítási és utastájékoztató rendszere... 9 2.2. Utazástervező rendszerek... 10 2.2.1. Google Maps... 10 2.2.2. A BKK saját útvonaltervező szolgáltatása... 11 2.2.3. Mobilalkalmazások utazástervezéshez... 11 2.2.4. Közösségi útvonaltervezés és közlekedésszervezés... 13 2.3. Közösségi közlekedési adatok... 14 2.3.1. Alapfogalmak... 14 2.3.2. Adatformátumok... 14 2.3.3. A közösségi közlekedési adatok felépítése... 16 3. Kísérleti mérésadatgyűjtő rendszer... 18 3.1. A mérésadatgyűjtő rendszer architektúrája és implementációja... 18 3.2. Adatgyűjtő szoftver... 19 3.2.1. Az adatgyűjtés ütemezése... 19 3.2.2. Az adatok annotálása és feltöltése... 21 3.2.3. Adatvédelem... 21 3.3. Gyűjtött adatok... 21 3.3.1. Földrajzi adatok... 21 3.3.2. Gyorsulásmérő és más szenzorok... 23 3.3.3. Tömegközlekedési adatok... 24 4. Az adatok elemzése... 25 4.1. Földrajzi adatok feldolgozása... 25 4.1.1. A földrajzi adatok tárolása... 25 4.1.2. A Futár és a készülék helyadatainak egyeztetése... 26 4.1.3. Valós idejű működés... 32 4.1.4. A módszer teljesítőképessége és korlátai... 32 4.2. Szenzoradatok elemzése... 33 4.2.1. Korábbi munkák... 33 4.2.2. Adatok kiválogatása és címkézése... 33 4.2.3. Adatok előkészítése... 34 4.2.4. Feature kinyerés... 35 3

4.2.5. Tanulás és az eredmények kiértékelése... 38 4.2.6. Gyorsítási lehetőségek... 39 4.2.7. Végrehajtás a készüléken... 40 4.3. Földrajzi és szenzoros adatok összevetése... 40 5. Prototípus rendszer... 42 5.1. Rendszer architektúrája... 42 5.2. A szolgáltatás egyéni hasznosítása... 43 5.2.1. Átszállási idő becslése... 43 5.2.2. Útvonaltervezés... 43 5.2.3. Navigáció... 43 5.2.4. Útvonaltervezés és navigáció rendkívüli események esetén... 43 5.2.5. Szokásokhoz igazodó javaslatok... 43 5.3. Eredmények közösségi hasznosítása... 44 5.3.1. Járművekre vonatkozó statisztikák... 44 5.3.2. Közlekedési vállalatok számára adatgyűjtés... 44 5.4. Továbblépési lehetőségek... 44 5.4.1. A javasolt megoldás kiterjesztése más városokra... 44 5.4.2. További okostelefonos rendszerek támogatása... 45 6. Összefoglalás... 46 Köszönetnyilvánítás... 47 Irodalomjegyzék... 48 4

1. Bevezetés és motiváció 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 szenzorok 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. Az 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 javításához is hozzájárulhatnak, valamint további területeken is felhasználhatóak. A dolgozat célja olyan adatgyűjtési és feldolgozási módszerek kidolgozása, amelyek technikai alapot biztosítanak egy ilyen közösségi közlekedési szolgáltatásokat nyújtó prototípus rendszer megvalósulásához. Ehhez elsőként egy olyan rendszer ké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 el lehet tárolni. Az egyéni hely- és szenzoradatok földrajzi és adatbányászati elemzésén keresztül a dolgozat bemutatja a velük elérhető eredményeket, majd áttekinti, hogy hogyan lehet a két módszert összekapcsolni, és ezáltal hatékonyabban alkalmazni a prototípus rendszerben a személyre szabott útvonaltervezéshez szükséges átszállási idő becsléséhez, valamint a navigációhoz szükséges járatmeghatározáshoz. A felhasználók számára hasznos szolgáltatások mellett a rendszer által előállított adatok alkalmasak arra is, hogy a közlekedési szolgáltatónak visszajelzést, statisztikákat tudjon adni, ezáltal segítve a tömegközlekedésnek az utasok számára legjobb irányban történő fejlődését. 5

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 három különböző rendszerről van szó a dolgozatban, amelyek egymásra épülnek: a 3. fejezet egy kísérleti mérésadatgyűjtő rendszert mutat be, amire az adatok gyűjtéséhez volt szükség. A 3.3. alfejezet emellett ismerteti a mért adatok jellegét is. A 4. fejezet 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. Az 5. fejezetben a dolgozat ismerteti az elemzett adatokat felhasználó prototípus szolgáltatást: ez a rendszer a kísérleti mérőrendszer tapasztalatai alapján immár hatékony módon tud adatot gyűjteni és azokat a szolgáltatás biztosítására felhasználni. Ezen kívül áttekintésre kerülnek a további lehetőségek, hogy milyen irányokba továbbhaladva lehet elérni egy kész, nyilvános működésre képes rendszert. Végül a 6. fejezet összefoglalja az elért eredményeket. 6

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), illetve 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ő számára szabottan 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. Sok más (pl. közútfejlesztések, parkolásszervezés, taxifelügyelet) mellett a tömegközlekedést is ők irányítják, ő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 az utóbbi években a BKK Futár (Forgalomirányítási és UtasTÁjékoztatási Rendszer) bevezetése nagy előrelépést jelentett. 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. A rendszer másik lényeges pontja, az utastájékoztatás pedig az így elérhetővé vált adatokkal történik, például a 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] 7

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, valamint a megállókba kihelyezett oszlopokon. 8

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 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, melynek eredményeképpen 2011 augusztusa óta a vonatok pozíciója élőben követhető a MÁV Vonatinfó oldalán. [7] 5. ábra: A MÁV Vonatinfó oldala. [8] Az oldal mutatja a magyarországi személyszállító vonatok pozícióját és esetleges késését. 9

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 1. és a 2. táblázat összefoglalja a jelenleg létező, a budapesti közösségi közlekedésről információt nyújtó szolgáltatásokat webes, illetve mobil rendszereken. 1. táblázat: Budapesti közösségi közlekedési útvonaltervező weboldalak Menetrend Útvonalterv Élő adatok Google Maps igen igen indulási időpontok, rendkívüli események Bing Maps igen igen nincs BKK Futár igen igen indulási időpontok, útvonaltervezés, élő járműpozíciók BKK Info nem nem 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 BKK Futár Google Maps Rendszer Menetrend Útvonalterv Élő adatok Android, ios, Windows Phone Android, ios online online online online menetrend, útvonaltervezés menetrend, rendkívüli események Android letöltés, értékelés 10-50e, 3,8 1-5 mrd, 4,3 Bing Maps Windows Phone online online nincs - BKK Info Android, rendkívüli nincs nincs ios események 50-100e, 3,7 Budapesti menetrend Android offline offline járműpozíciók 100-500e, 4,7 BPMenetrend Android offline nincs nincs 100-500e, 4,2 Smart City Android, ios offline offline nincs 50-100e, 4,1 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 tömegközlekedési útvonaltervezésre Budapesten is [9], 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. [10] 10

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, ami a Futár rendszerből származó élő adatokkal dolgozik. Ezen kívül a szolgáltatás 2014 novembere óta a Mol Bubi közösségi kerékpáros rendszerrel is össze lett hangolva. [5] 6. ábra: Online útvonaltervező alkalmazások útvonaltervei ugyanarra az útvonalra és indulási időpontra. Balra: Google Maps, középen: Bing Maps, jobbra: BKK Futár 2.2.3. Mobilalkalmazások utazástervezéshez 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ézni a menetrendet. 7. ábra: Az okostelefonok elterjedtsége Magyarországon. (Forrás: [11]) Bal oldalon a korosztályi eloszlás látható 2012-ben (szürke) és 2013-ban (zöld), jobb oldalon pedig az okostelefonnal rendelkező 14 éven felüli személyek száma. 11

2010. november 2011. január 2011. március 2011. május 2011. július 2011. szeptember 2011. november 2012. január 2012. március 2012. május 2012. július 2012. szeptember 2012. november 2013. január 2013. március 2013. május 2013. július 2013. szeptember 2013. november 2014. január 2014. március 2014. május 2014. július 2014. szeptember 2014. november Ma az okostelefonok világszerte rohamosan terjednek. Magyarországon 2014 végére várhatóan a 14 év feletti korosztály 36%-a rendelkezni fog ilyen készülékkel. 80 70 60 50 40 30 20 10 0 Android ios SymbianOS Windows Phone Samsung Bada 8. ábra: Az okostelefonok operációs rendszereinek elterjedtsége Magyarországon 2010 és 2014 novembere között. (Forrás: [12]) 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, a telefonok 15%-án ios, 7%-án pedig Windows Phone rendszer működik. Emiatt a magyar piacra tervezett alkalmazások nagy része elsősorban az Android rendszert célozza meg. 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. [13] 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, valamint megtekinthető benne minden megállónál, hogy mikor indulnak onnan autóbuszok. [14] 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 megadható, hogy melyek a gyakran használt útvonalak, és ha azokon történik valami rendkívüli esemény, akkor szól a felhasználónak. [15] 12

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. [16] BPMenetrend: az alkalmazás: offline (statikus) menetrendet biztosít a felhasználóknak. Ez az alkalmazás volt az első ilyen androidos alkalmazás, így jelenleg is sok felhasználó használja. [17] Smart City: az alkalmazás offline menetrendet és útvonaltervezést biztosít Android és ios rendszerekre. [18] 9. ábra: A különböző mobilos útvonaltervező alkalmazások felületei. 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 Közösségen alapuló útvonaltervezésre, illetve közlekedésszervezésre vannak már létező megoldások az elmúlt évekből. Az egyik ilyen a Google Maps autós útvonaltervezése, ami a felhasználók mobiltelefonjai által küldött adatok 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. [19] Egy másik, a dolgozatban bemutatotthoz hasonló próbálkozás az AllAboard rendszer, ami a közlekedés általános működéséről, a város lakóinak mozgásáról gyűjt és ad tovább információt a közlekedési szolgáltatóknak, melyeket a mobilszolgáltatók által a rendelkezésükre bocsátott cellaadatokból állít elő. [20] 13

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 a fejezet 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 a jelenlegi legelterjedtebb adatformátumokat, illetve az adatok egymáshoz kapcsolódását. 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: Viszonylat: viszonylat (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 [21], azaz például a 19-es villamos vagy a 7-es busz. Járat: a járat (esetleg 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. Jármű: a jármű (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. 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. Megálló: az adatbázis szempontjából egy megállónak (stop) általában egy jármű megállási helye számít, azaz általában minden megállótáblához külön azonosító tartozik. Ez alól Budapesten kivételek 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ó. 2.3.2. Adatformátumok A BKK a fejlesztők számára 2011 júniusa óta elérhetővé teszi a statikus menetrendet GTFS formátumban, várhatóan 2014 végétől pedig az élő járműadatokat is GTFS-RT formátumban. A GTFS (General Transit Feed Specification) a Google által kifejlesztett, csv alapú adatformátum tömegközlekedési menetrendek leírására [22]. 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 14

jelölése. A budapesti GTFS fájl a fent leírt attribútumok mellett tartalmaz információkat például a járművek alacsonypadlósságáról is. 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 szabványos formában közzétehetik a járművek élő információit [23]. 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, illetve ígéretet tett arra, hogy ezt a későbbiekben majd minden fejlesztő használhatja. 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. 15

2.3.3. A közösségi közlekedési adatok felépítése 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 megállók adatai: Megálló azonosítója (pl. 008591 : Szent Gellért téri villamosmegálló észak felé) Megálló megjelenítésre használatos neve (pl. Szent Gellért tér M ) Megálló koordinátái (szélességi és hosszúsági koordináták) A viszonylatok fontosabb adatai: Viszonylat azonosítója (a viszonylatjelzésből előállítva, pl. 107-es busz: 1070, 19-es villamos: 3190 ) Viszonylat neve (a viszonylatjelzés, pl. 19 vagy M4 ) Viszonylat típusa (pl. autóbusz, villamos, metró) A járatok adatai: Viszonylat azonosítója Járat azonosítója (pl. B164431506 ) Járat célállomása Járat útvonalának koordinátái (végállomástól kezdve a pontok listája) Járat menetrend szerinti megállói, illetve az érkezés és az indulás menetrend szerinti időpontjai A Futár járműadatai a következők: Adat letöltésének időpontja (dátum és idő, másodperc pontossággal) Jármű azonosítója (Futár rendszerből származó azonosító) Következő megálló azonosítója: GTFS azonosítószáma a megállóhelynek (pl. 008591 ) Viszonylat azonosítója: GTFS azonosítószáma a viszonylatnak (pl. 3190 ) Jármű pozíciója (szélességi és hosszúsági fok) Jármű irányszöge (fok északhoz képest) Jármű rendszáma vagy pályaszáma (pl. BPI297 vagy V4073 (villamos)) Jármű típusa (pl. Tátra T5C5K villamos vagy Mercedes Citaro O 530 autóbusz) Jármű pozíció utolsó frissítésének időpontja (dátum és idő, másodperc pontossággal) Jármű járatazonosítója: GTFS azonosítószáma a járatnak (pl. B164431506 ) A következő oldalon a 12. ábra bemutatja, hogy ezek az adatok hogyan kapcsolódnak egymáshoz. 16

12. ábra: A menetrendi és az élő adatok egymástól függése. Bal oldalon az állandó menetrendi adatok láthatók, jobb oldalon pedig a valós idejű adatok, illetve azok kapcsolódása a statikus menetrendhez. 17

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. A rendszer segítségével másfél hónapon keresztül 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), illetve a mért adatok alapvető tulajdonságait (3.3. 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ítette a BKK élő járműadatait, illetve a statikus menetrendet is. A mérésadatgyűjtő rendszer elkészült, a kliens Android 4.0-s vagy újabb rendszereken érhető el. Az adatgyűjtők számára az alkalmazás a Google Play Store-on 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 nincs szükség a szerver stabil és teljesen folyamatos működésére (egy esetleges áram- vagy 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), 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 lehet felállítani, így elkerülve a felhőszolgáltatások magasabb adattárolási költségét. 18

Az adatgyűjtéshez használt szerver egy Windows Server 2012 R2-t futtató Mini-ITX alacsony fogyasztású számítógép lett, 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ést az ismerősi körömben terjesztett Androidos mobilalkalmazással valósítottam meg. 18 készülékkel (14 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 első változata minden adatot rögzít a rögzítés elindítása után egészen a leállításáig. Így 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. A prototípus rendszer szempontjából már fontos lesz, hogy az adatgyűjtés minél kevesebb energiát, illetve adatforgalmat használjon. Ez egyrészt az adatgyűjtés intelligens indításával oldható meg, másrészt pedig a már folyamatban levő adatgyűjtés optimalizálásával. Ebből adódóan sokkal kevesebb adat gyűlik össze, mint folyamatos rögzítés esetén, ami ront a detekciók és az adatfeldolgozás hatékonyságán. Így fontos azt 19

megvizsgálni, hogy milyen módosítások milyen mértékben csökkentik ezeknek a funkcióknak a teljesítőképességét. 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ált energia és adatmennyiség csökkentése emellett a szenzoradatok szakaszos rögzítésével is megoldható, azaz ha az alkalmazás nem rögzít minden adatot, csak adott időközönként, valamint ha ritkább mintavételezési frekvenciát használ, vagy pedig 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 térképes nézet látszik a feltöltendő pontokkal, középen a tevékenységrögzítés képernyő, jobb oldalon pedig az alkalmazás beállításai 20

3.2.2. Az adatok annotálása és feltöltése A felhasználó az 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 14. ábra középső képernyőképén megtekinthető. A gyűjtött adatokat az adatgyűjtő 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. 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. Emellett fontos volt figyelembe venni a felhasználók adatainak védelmét is. Egy helyadatokat is gyűjtő alkalmazás esetében különösen lényeges, 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. 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 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ó. 21

Előfordulások száma 15. ábra: Gyűjtött helyadatok Budapesten. Az ábrán 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. A dolgozat elkészítéséig az alkalmazás használatával a felhasználók több mint 340 000 adatpontot gyűjtöttek. Az adatpontok nagy része, 300 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 jelenleg a 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 megváltozik. 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 Időtartam (mp) 16. á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. 22

0 1-10 10-20 20-30 30-40 40-50 50-60 60-70 Adatpontok száma ezer Amint az a 16. ábrán is látszik, a beérkezett adatok alapján viszonylag sűrűn, átlagosan 3-4 másodpercenként történt helyadatfrissítétés. 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. 120 100 80 60 40 20 0 Sebesség (km/h) 17. ábra: A sebességértékek eloszlása a GPS-szel mért adatoknál A gyűjtött adatok sebesség alapján is megvizsgálásra kerültek, ennek eredménye a 17. ábrán látható. A hisztogram alapján az adatok jellegbeli eloszlása meghatározható: megközelítőleg 100 000 db közel 0 sebességű adatpont (várakozás vagy megállás), szintén 100 000 1-10 km/h-s sebességű adatpont (gyaloglás vagy lassú utazás), és hasonló mennyiségű magasabb sebességű utazás közben gyűjtött pontot mértek az adatgyűjtők. 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 a szenzorokkal. 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álja gyűjteni az alkalmazás. Amint az a 18. á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 az esetek többségében kb. 5 msos sűrűséggel, azaz 200 Hz-es frekvenciával biztosítani a mintavételt, ami elegendő pontosságot biztosít a hatékony tevékenységfelismeréshez. 23

Előfordulások száma <0,5 0,5 1 1 1,5 1,5 2 2 2,5 2,5 3 3 3,5 3,5 4 4 4,5 4,5 5 5 5,5 5,5 6 6 6,5 6,5 7 7 7,5 7,5 8 8 8,5 8,5 9 9 9,5 9,5 10 >10 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Eltelt idő két egymás utáni adat között (ms) 18. ábra: A szenzoradatok mintavételi idejének eloszlása különböző készülékek esetén. A különböző színek a különböző készülékeket jelentik, az oszlopok magassága pedig az adott időközhöz tartozó arányát mutatja az adatoknak. 3.3.3. Tömegközlekedési adatok A jármű meghatározását végző algoritmusnak szüksége van a BKK Futár rendszer adataira ahhoz, hogy meg tudja határozni a jármű élő pozícióját. Ez a futar.bkk.hu élő járműadatainak folyamatos mentésével lett megvalósítva, mivel a program elkészítésekor a publikus GTFS-RT feed még nem volt 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. Ezeket az adatokat elég központilag, egyszer lementeni, így ezeket nem a felhasználók készülékei, 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) 19. á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. 24

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 mutatja be, hogy a kétféle módszer összevonásával milyen eredmény állítható elő. 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. [24] 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 ezek mellé a GPS szenzor által meghatározott sebesség-, irányszög-, illetve magasságértéket is. Emellett ekkor sokkal sűrűbben kap adatot a rendszer, a 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 kiegészítővel ellátott PostgreSQL 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, 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 Futár rendszerből érkező élő 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) Helyadat pontossága (becsült méter) Eszköz azonosítója 25

4.1.2. A Futár és a készülék helyadatainak egyeztetése Mivel a Futár adatok é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 16. és a 19. ábrákon is látható, sokkal sűrűbben rendelkezésre áll készüléktől származó helyadat, mint a Futár rendszerből származó járműhelyadat, ezért a felhasználói helyadatok mentén érdemes interpolálni, mivel így pontosabb görbét kapunk. 20. á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ú 41- es 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. 26

21. á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. 22. á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 27

Az interpoláció során ki lehet számolni, hogy hol tartózkodott a felhasználó a helyadatai alapján a Futár adat é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 jelenleg 3 percre visszamenőleges útvonalszakaszok minden adatponthoz ennyi idő alatt átlagosan 5-6 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 Futár rendszer által használt és a felhasználó által használt időpont legalább megközelítőleg (1-2 mp-es eltéréssel) szinkronban legyen. Ez az okostelefonok esetében nem probléma, mivel rendszeresen szinkronizálják az időt a mobilszolgáltatón keresztül, és a tapasztalatok alapján a Futár rendszernél sem okoz problémát. 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ű. 23. ábra: Egy kiválasztott pont és az azelőtt legfeljebb 3 perccel érkező összes járműadat 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ó. 28

A 24. á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). 24. á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. 3. táblázat: Az adatpontok távolsága helytelen becslés során Időpont Távolság 2014-10-14 20:18:08+02 82,6 m 2014-10-14 20:18:39+02 82,8 m 2014-10-14 20:18:57+02 103,4 m 2014-10-14 20:19:17+02 213,6 m 2014-10-14 20:19:27+02 179,0 m 2014-10-14 20:19:59+02 23,8 m 2014-10-14 20:20:30+02 102,1 m 2014-10-14 20:20:41+02 118,0 m Az adatokból két mérőszámot számol az alkalmazás: 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. Ezen adatok súlyozott átlaga 112,2 m, és látszik, hogy vannak sokkal távolabbi adatok is (a négyzetes pontosság értéke 1983), így megállapítható, hogy valószínűleg nem ezzel utazott a felhasználó. 29

A 25. á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. 25. á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). 4. táblázat: Az adatpontok távolsága helyes becslés esetén Időpont Távolság 2014-10-14 20:17:59+02 37,1 m 2014-10-14 20:18:32+02 35,1 m 2014-10-14 20:18:51+02 51,7 m 2014-10-14 20:19:04+02 63,6 m 2014-10-14 20:19:36+02 46,2 m 2014-10-14 20:19:46+02 11,5 m 2014-10-14 20:20:19+02 45,6 m 2014-10-14 20:20:26+02 42,0 m Ezen adatok már sokkal kisebbek, a súlyozott átlaguk 42,3 m, a négyzetes pontossági érték pedig 241. 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 a felhasználó sem mindig a jármű elejében utazik, ahol a jármű Futár modulja található. (A példában bemutatott villamos 27 m hosszú.) 30

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): 5. 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 Átlagos távolság Adatpontok száma 1401 villamos 41 42 m 8 1446 villamos 49 112 m 8 BPO-576 autóbusz 107 176 m 8 1400 villamos 19 308 m 8 FJX-212 autóbusz 86 389 m 4 FJX-211 autóbusz 133 450 m 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 26. ábrán látható eredményt adta. 26. á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). 31

4.1.3. Valós idejű működés Mobilinternetes kapcsolat mellett az is megvalósítható, hogy a telefon pontosan tudja, hogy a felhasználó éppen melyik járművön utazik. Amennyiben rendelkezésre állnak a jármű élő helyadatai, akkor a készülék a korábbi helyadatait egy szolgáltatásnak feltöltve az a historikus járműadatokat használva ugyanazzal a módszerrel meg tudja határozni élőben a felhasználó által használt járművet, mint ahogyan azt utólag tenné. Amivel itt számolni kell, az az, hogy van egy néhány másodperces késés a futár adatok keletkezésének ideje és az adatok elérhetővé válásának ideje között. 4.1.4. A módszer teljesítőképessége és korlátai A módszer pontos meghatározást biztosított akkor, ha a felhasználó már egy ideje azon a járművön utazott. Eltévesztette azonban a járművet az algoritmus egyrészt akkor, amikor még nem állt rendelkezésre elegendő mennyiségű helyadat ahhoz, hogy ráillessze az útvonalát a jármű útvonalára, másrészt a leszállás utáni időszakban, amikor még úgy érezte, hogy elég jól illeszkednek a pontok a járműre ahhoz, hogy bízzon azokban. Viszont ezekben az esetekben is többnyire tudta az algoritmus a bizonytalansági tényező alapján, hogy nem biztos, hogy sikerült eltalálnia a járművet. Ezeken kívül 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, 2014 novemberé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 2015 elején várható. [25] 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. Mivel a módszer kauzális, azaz csak a múltbeli adatokat használja fel, nem nézi, hogy a jövőben hol lesz a jármű vagy a felhasználó, ezért alkalmas arra, hogy valós időben meghatározza a felhasználó helyzetét. A módszer további pontosításáról a 4.3. fejezetben lesz szó. 32

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ó lényege, hogy előre ismert tanulóadatok és egy azokhoz rendelt eredmény ismeretében egy olyan módszert állítsunk elő, amelynek segítségével képesek vagyunk az adatokból ismeretlen eredmény esetén is eldönteni, hogy mi az eredmény. Jelen esetben az ismert értékek a telefon által visszaadott szenzoradatok, a kérdéses eredmény 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ő, lift, mozgólépcső 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 felismerésével ([26], [27]), illetve közlekedési mód felismeréséről is találni irodalmat ([28], [29], [30]). 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 33

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, és 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/s 2. 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/s 2 nagyságú vektor függőlegesen felfele irányban, a telefon koordinátarendszerében. 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 [31], 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. 27. ábra: Gyorsulásmérő szenzor függőleges irányú komponensének adatai 34

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 felle 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 [32], illetve [30]) megismerése és a számításigények mérlegelése után az alábbi feature-ök kerültek felhasználásra: Maximum: A maximális érték periodikus értékek esetén meghatározza, hogy mi a hullám maximális értéke (28. ábra). Átlag: Az átlagos szenzorérték megmutatja, hogy mekkora a vektor átlagos nagysága az adott időablakban (29. á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 (30. á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 35

é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. (31. és 32. ábra) 28. ábra: Maximális gyorsulásmérő adatok 5 mp-es időablakon 29. ábra: Gyorsulásmérő adatok átlaga 5 mp-es időablakon 30. ábra: A gyorsulásmérő adatok integrálja 5 mp-es időablakon 36

31. á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. 32. ábra: A jel és Fourier-transzformáltja a t=200 s időpontban (gyaloglás). 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). [33] 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. 37