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

Méret: px
Mutatás kezdődik a ... oldaltól:

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

Átírás

1 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.

2 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

3 Tartalom Absztrakt Bevezetés és motiváció Közösségi közlekedési rendszerek Forgalomirányító és utastájékoztató rendszerek Budapest forgalomirányítási és utastájékoztatási rendszere A Kisalföld Volán forgalomirányítási és utastájékoztatási rendszere A MÁV forgalomirányítási és utastájékoztató rendszere Utazástervező rendszerek Google Maps A BKK saját útvonaltervező szolgáltatása Mobilalkalmazások utazástervezéshez Közösségi útvonaltervezés és közlekedésszervezés Közösségi közlekedési adatok Alapfogalmak Adatformátumok A közösségi közlekedési adatok felépítése Kísérleti mérésadatgyűjtő rendszer A mérésadatgyűjtő rendszer architektúrája és implementációja Adatgyűjtő szoftver Az adatgyűjtés ütemezése Az adatok annotálása és feltöltése Adatvédelem Gyűjtött adatok Földrajzi adatok Gyorsulásmérő és más szenzorok Tömegközlekedési adatok Az adatok elemzése Földrajzi adatok feldolgozása A földrajzi adatok tárolása A Futár és a készülék helyadatainak egyeztetése Valós idejű működés A módszer teljesítőképessége és korlátai Szenzoradatok elemzése Korábbi munkák Adatok kiválogatása és címkézése Adatok előkészítése Feature kinyerés

4 Tanulás és az eredmények kiértékelése Gyorsítási lehetőségek Végrehajtás a készüléken Földrajzi és szenzoros adatok összevetése Prototípus rendszer Rendszer architektúrája A szolgáltatás egyéni hasznosítása Átszállási idő becslése Útvonaltervezés Navigáció Útvonaltervezés és navigáció rendkívüli események esetén Szokásokhoz igazodó javaslatok Eredmények közösségi hasznosítása Járművekre vonatkozó statisztikák Közlekedési vállalatok számára adatgyűjtés Továbblépési lehetőségek A javasolt megoldás kiterjesztése más városokra További okostelefonos rendszerek támogatása Összefoglalás Köszönetnyilvánítás Irodalomjegyzék

5 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

6 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

7 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) 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) 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

8 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 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

9 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 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

10 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 e, 3,7 Budapesti menetrend Android offline offline járműpozíciók e, 4,7 BPMenetrend Android offline nincs nincs e, 4,2 Smart City Android, ios offline offline nincs e, 4, Google Maps A Google Maps jelenleg az egyik legnépszerűbb térkép- és útvonaltervező szolgáltatás 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

11 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 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

12 2010. november január március május július szeptember november január március május július szeptember november január március május július szeptember november január március május július szeptember 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 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

13 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 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 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

14 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 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ó 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

15 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

16 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 : 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. B ) 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 ) Viszonylat azonosítója: GTFS azonosítószáma a viszonylatnak (pl ) 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. B ) A következő oldalon a 12. ábra bemutatja, hogy ezek az adatok hogyan kapcsolódnak egymáshoz. 16

17 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

18 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) 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

19 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 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 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

20 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

21 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 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 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 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

22 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 adatpontot gyűjtöttek. Az adatpontok nagy része, 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 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

23 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 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 db közel 0 sebességű adatpont (várakozás vagy megállás), szintén 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 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

24 Előfordulások száma <0,5 0, ,5 1, ,5 2, ,5 3, ,5 4, ,5 5, ,5 6, ,5 7, ,5 8, ,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 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 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

25 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ő 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ő 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 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

26 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

27 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

28 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

29 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 :18: ,6 m :18: ,8 m :18: ,4 m :19: ,6 m :19: ,0 m :19: ,8 m :20: ,1 m :20: ,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

30 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 :17: ,1 m :18: ,1 m :18: ,7 m :19: ,6 m :19: ,2 m :19: ,5 m :20: ,6 m :20: ,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

31 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 m villamos m 8 BPO-576 autóbusz m villamos m 8 FJX-212 autóbusz m 4 FJX-211 autóbusz 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

32 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 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

33 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.) 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 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

34 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 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

35 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 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

36 é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

37 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

FUTÁR projekt A forgalomirányítási és utastájékoztatási rendszer fejlesztése

FUTÁR projekt A forgalomirányítási és utastájékoztatási rendszer fejlesztése FUTÁR projekt A forgalomirányítási és utastájékoztatási rendszer fejlesztése 2012. szeptember 18. Berger András projektvezető Budapesti Közlekedési Központ FUTÁR projekt célok és eszközök Célok A közösségi

Részletesebben

Innovatív technológiák a fővárosi közlekedés megújításában. Vitézy Dávid vezérigazgató Budapesti Közlekedési Központ 2014. november 6.

Innovatív technológiák a fővárosi közlekedés megújításában. Vitézy Dávid vezérigazgató Budapesti Közlekedési Központ 2014. november 6. Innovatív technológiák a fővárosi közlekedés megújításában Vitézy Dávid vezérigazgató Budapesti Közlekedési Központ 2014. november 6. Tartalom Fontosabb eredmények Intelligens rendszerek Fejlesztések 2

Részletesebben

Járműkövető rendszer RÉSZLETES ISMERTETŐ

Járműkövető rendszer RÉSZLETES ISMERTETŐ efollow Járműkövető rendszer RÉSZLETES ISMERTETŐ Tartalomjegyzék 1.1. BEVEZETÉS...3 1.2. JÁRMŰKÖVETŐ RENDSZER FELADATA...3 2.1. MIT TUD AZ EFOLLOW?...3 2.2. MILYEN JÁRMŰADATOKAT MÉR JELENLEG A RENDSZER?...3

Részletesebben

FELHASZNÁLÓI KÉZIKÖNYV

FELHASZNÁLÓI KÉZIKÖNYV FELHASZNÁLÓI KÉZIKÖNYV SZEGED VÁROS KÖZLEKEDÉSE 1.00 verzió Dátum: 2012.02.29. Tartalom 1. Rendszerigény... 3 2. Bevezető... 3 3. Az alkalmazás indítása... 3 4. Az oldal felépítése... 4 4.1. Főképernyő...

Részletesebben

BusEye online személyre szabott utastájékoztató mobil alkalmazás fejlesztése

BusEye online személyre szabott utastájékoztató mobil alkalmazás fejlesztése BusEye online személyre szabott utastájékoztató mobil alkalmazás fejlesztése Közlekedéstudományi Konferencia Hazai és nemzetközi projektek a közlekedésben Győr, 2014. március 27-28. BME - Közlekedésüzemi

Részletesebben

FELHASZNÁLÓI KÉZIKÖNYV XMAP (EXTENDED MAP) KEZELÉSI ÚTMUTATÓ (TATABÁNYA VÁROS KÖZLEKEDÉSE)

FELHASZNÁLÓI KÉZIKÖNYV XMAP (EXTENDED MAP) KEZELÉSI ÚTMUTATÓ (TATABÁNYA VÁROS KÖZLEKEDÉSE) FELHASZNÁLÓI KÉZIKÖNYV XMAP (EXTENDED MAP) KEZELÉSI ÚTMUTATÓ (TATABÁNYA VÁROS KÖZLEKEDÉSE) 1. Bevezető Az XMap egy korszerű, internetes, böngésző alapú, térképes utastájékoztató szoftver. Jelenleg Tatabánya

Részletesebben

Leolvasói rendszer kialakításának koncepciója ipari mobil eszközökkel (ipari PDA-val)

Leolvasói rendszer kialakításának koncepciója ipari mobil eszközökkel (ipari PDA-val) Leolvasói rendszer kialakításának koncepciója ipari mobil eszközökkel (ipari PDA-val) A leolvasási feladat AS Szerver DB Számlázási, ügyfélszolgálati adatbázis Adatgyűjtő szerver Mobil adatgyűjtő AS szerver

Részletesebben

Városi tömegközlekedés és utastájékoztatás szoftver támogatása

Városi tömegközlekedés és utastájékoztatás szoftver támogatása Városi tömegközlekedés és utastájékoztatás szoftver támogatása 1. Általános célkitűzések: A kisvárosi helyi tömegközlekedés igényeit maximálisan kielégítő hardver és szoftver környezet létrehozása. A struktúra

Részletesebben

Robotika. Relatív helymeghatározás Odometria

Robotika. Relatív helymeghatározás Odometria Robotika Relatív helymeghatározás Odometria Differenciális hajtás c m =πd n /nc e c m D n C e n = hány mm-t tesz meg a robot egy jeladó impulzusra = névleges kerék átmérő = jeladó fölbontása (impulzus/ford.)

Részletesebben

Oszkar.com Android alkalmazás v1.2

Oszkar.com Android alkalmazás v1.2 Oszkar.com Android alkalmazás v1.2 Az 1.2 verzióban a következő funkciók érhetők el: Be- kijelentkezés Autós ajánlatok keresése, akár dátum intervallumra Pontos és közeli ajánlatok megjelenítése Autós

Részletesebben

MOBIL TÉRKÉPEZŐ RENDSZER PROJEKT TAPASZTALATOK

MOBIL TÉRKÉPEZŐ RENDSZER PROJEKT TAPASZTALATOK MOBIL TÉRKÉPEZŐ RENDSZER PROJEKT TAPASZTALATOK GISopen 2011 2011. március 16-18. Konasoft Project Tanácsadó Kft. Maros Olivér - projektvezető MIÉRT MOBIL TÉRKÉPEZÉS? A mobil térképezés egyetlen rendszerben

Részletesebben

FELHASZNÁLÓI KÉZIKÖNYV SCHEDULEDETAIL KEZELÉSI ÚTMUTATÓ (DEBRECEN VÁROS KÖZLEKEDÉSE) 1.00 verzió Dátum: 2013.09.05

FELHASZNÁLÓI KÉZIKÖNYV SCHEDULEDETAIL KEZELÉSI ÚTMUTATÓ (DEBRECEN VÁROS KÖZLEKEDÉSE) 1.00 verzió Dátum: 2013.09.05 FELHASZNÁLÓI KÉZIKÖNYV (DEBRECEN VÁROS KÖZLEKEDÉSE) 1.00 verzió Dátum: 2013.09.05 Tartalom 1. Rendszerigény... 3 2. Bevezető... 3 3. Az alkalmazás indítása... 3 4. Az oldal felépítése... 4 4.1. Főképernyő...

Részletesebben

CHARACTERIZATION OF PEOPLE

CHARACTERIZATION OF PEOPLE CONFERENCE ABOUT THE STATUS AND FUTURE OF THE EDUCATIONAL AND R&D SERVICES FOR THE VEHICLE INDUSTRY CHARACTERIZATION OF PEOPLE MOVEMENT BY USING MOBILE CELLULAR INFORMATION László Nádai "Smarter Transport"

Részletesebben

DLM PULSE - PREDIKTÍV TÁRGYALÁS TÁMOGATÓ ALKALMAZÁS DLM PULSE

DLM PULSE - PREDIKTÍV TÁRGYALÁS TÁMOGATÓ ALKALMAZÁS DLM PULSE DLM PULSE - PREDIKTÍV TÁRGYALÁS TÁMOGATÓ ALKALMAZÁS DLM PULSE A DLM Pulse innovatív testbeszéd kiértékelő megoldás virtuális tanácsadóként segíti az értékesítő munkáját az üzleti tárgyalás során. Könnyen

Részletesebben

Haladó mozgások A hely és a mozgás viszonylagos. A testek helyét, mozgását valamilyen vonatkoztatási ponthoz, vonatkoztatási rendszerhez képest adjuk

Haladó mozgások A hely és a mozgás viszonylagos. A testek helyét, mozgását valamilyen vonatkoztatási ponthoz, vonatkoztatási rendszerhez képest adjuk Haladó mozgások A hely és a mozgás viszonylagos. A testek helyét, mozgását valamilyen vonatkoztatási ponthoz, vonatkoztatási rendszerhez képest adjuk meg, ahhoz viszonyítjuk. pl. A vonatban utazó ember

Részletesebben

vbar (Vemsoft banki BAR rendszer)

vbar (Vemsoft banki BAR rendszer) vbar (Vemsoft banki BAR rendszer) BAR bemutatása 1994. július 1-jétől kezdte meg működését a Központi Adós- és Hitelinformációs Rendszer, azóta is használt rövidített nevén a BAR, amely kezdetben kizárólag

Részletesebben

READy Suite: mobil és fix kiolvasó hálózat fogyasztásmérőkhöz

READy Suite: mobil és fix kiolvasó hálózat fogyasztásmérőkhöz READy Suite: mobil és fix kiolvasó hálózat fogyasztásmérőkhöz Drive-by Okos telefon Multiterm Pro Kézi eszközzel történő mérőkiolvasás USB Meter Reader Fix hálózat Automatizált mérőleolvasás fix hálózaton

Részletesebben

A TransHUSK Plus projekt

A TransHUSK Plus projekt A TransHUSK Plus projekt dr. Siska Miklós KTI Zárókonferencia Győr, 2015. június 17. A projekt keretében vizsgált térségek A két projekt néhány jellemző adata 680 km közös határ; 22 (TransHUSK) + 18 (TransHUSK

Részletesebben

MÉRY Android Alkalmazás

MÉRY Android Alkalmazás MÉRY Android Alkalmazás Felhasználói kézikönyv Di-Care Zrt. Utolsó módosítás: 2014.06.12 Oldal: 1 / 7 Tartalomjegyzék 1. Bevezetés 3 1.1. MÉRY Android alkalmazás 3 1.2. A MÉRY Android alkalmazás funkciói

Részletesebben

transit TÜKE BUSZ Zrt. menetrend app Felhasználói kézikönyv Verzió: transit 1.2.12t HC LINEAR MŰSZAKI FEJLESZTŐ KFT.

transit TÜKE BUSZ Zrt. menetrend app Felhasználói kézikönyv Verzió: transit 1.2.12t HC LINEAR MŰSZAKI FEJLESZTŐ KFT. Felhasználói kézikönyv Verzió: transit 1.2.12t Kezdőképernyő Menetrend Vonalak listája Közeli megállók aktuális vagy választott pozíció alapján Kedvencek Kedvelt vonalak és megállók listája Beállítások

Részletesebben

A BKK jövőbeli az integrált közlekedésszervezést támogató térinformatikai tervei

A BKK jövőbeli az integrált közlekedésszervezést támogató térinformatikai tervei A BKK jövőbeli az integrált közlekedésszervezést támogató térinformatikai tervei Strausz György Gábor informatikai igazgató Budapesti Közlekedési Központ HUNAGI Konferencia 2012. március 21. Tartalom Új

Részletesebben

API-MÁGIA MILLIÓ SORNYI ADAT ÚJRARENDEZÉSE. Előadó: Jaksa Zsombor, drungli.com

API-MÁGIA MILLIÓ SORNYI ADAT ÚJRARENDEZÉSE. Előadó: Jaksa Zsombor, drungli.com API-MÁGIA MILLIÓ SORNYI ADAT ÚJRARENDEZÉSE Előadó: Jaksa Zsombor, drungli.com MIRŐL FOG SZÓLNI AZ ELŐADÁS? Hogyan működik a drungli.com?# Adatok gyűjtése, stratégiák# Ha marad időm még mesélek HOGYAN MŰKÖDIK

Részletesebben

Igényvezérelt közlekedés indítása Csúcshegy térségében

Igényvezérelt közlekedés indítása Csúcshegy térségében Igényvezérelt közlekedés indítása Csúcshegy térségében 1) A társadalmi egyeztetésen meghirdetett javaslatok A BKK kikérte a lakosság véleményét a Csúcshegy térségében az igényvezérelt közösségi közlekedés

Részletesebben

Mozgáselemzés MEMS alapúgyorsulás mérőadatai alapján

Mozgáselemzés MEMS alapúgyorsulás mérőadatai alapján Mozgáselemzés MEMS alapúgyorsulás mérőadatai alapján Nyers Szabina Konzulens: Tihanyi Attila Pázmány Péter Katolikus Egyetem Információs Technológia Kar Feladatok: Végezzen irodalom kutatást, mely tartalmazza

Részletesebben

A sínek tesztelése örvényáramos technológiákat használva

A sínek tesztelése örvényáramos technológiákat használva A sínek tesztelése örvényáramos technológiákat használva A DB Netz AG tapasztalatai DB Netz AG Richard Armbruster / Dr. Thomas Hempe/ Herbert Zück Fahrwegmessung / Fahrwegtechnik Békéscsaba, 2011.09.01.

Részletesebben

A budapesti közösségi közlekedés fejlesztései. Vitézy Dávid vezérigazgató Budapesti Közlekedési Központ 2014. május 22.

A budapesti közösségi közlekedés fejlesztései. Vitézy Dávid vezérigazgató Budapesti Közlekedési Központ 2014. május 22. A budapesti közösségi közlekedés fejlesztései Vitézy Dávid vezérigazgató Budapesti Közlekedési Központ 2014. május 22. Tartalom Keretek Megvalósult fejlesztések Folyamatban lévő fejlesztések További tervek

Részletesebben

Megoldások a tehergépjárműpihenők parkolóhely előrejelző rendszereire

Megoldások a tehergépjárműpihenők parkolóhely előrejelző rendszereire Megoldások a tehergépjárműpihenők parkolóhely előrejelző rendszereire Sándor Zsolt zsolt.sandor@mail.bme.hu Budapesti Műszaki és Gazdaságtudományi Egyetem Közlekedésmérnöki és Járműmérnöki Kar Közlekedésüzemi

Részletesebben

Optimális menetirányítás: stratégiák és implementálhatóság vizsgálata a FUTÁR projektben

Optimális menetirányítás: stratégiák és implementálhatóság vizsgálata a FUTÁR projektben Budapesti Műszaki és Gazdaságtudományi Egyetem Közlekedésmérnöki és Járműmérnöki Kar Közlekedés- és Járműirányítási Tanszék Optimális menetirányítás: stratégiák és implementálhatóság vizsgálata a FUTÁR

Részletesebben

Csatlakozási állapot megjelenítése

Csatlakozási állapot megjelenítése Csatlakozási állapot megjelenítése Ellenőrizheti a vevő és a jármű között a csatlakozás állapotát. Ezek a kapcsolatok felelősek az olyan információkért, mint a GPS információ és a parkolási jelzések. 1

Részletesebben

Innovatív technológiák a fővárosi közlekedés megújításában. Vitézy Dávid vezérigazgató Budapesti Közlekedési Központ 2014. november 6.

Innovatív technológiák a fővárosi közlekedés megújításában. Vitézy Dávid vezérigazgató Budapesti Közlekedési Központ 2014. november 6. Innovatív technológiák a fővárosi közlekedés megújításában Vitézy Dávid vezérigazgató Budapesti Közlekedési Központ 2014. november 6. Tartalom Fontosabb eredmények Intelligens rendszerek Fejlesztések 2

Részletesebben

1. Szolgáltatásaink. Adatok feltöltése és elemzése. Digitális feltöltés. Analóg korong feltöltés

1. Szolgáltatásaink. Adatok feltöltése és elemzése. Digitális feltöltés. Analóg korong feltöltés v 1.1 1. Szolgáltatásaink Adatok feltöltése és elemzése A Tacho-X rendszer képes a digitális, valamint analóg tachográfból korongokból származó adatokat beolvasni, és elemezni azokat. Az beolvasott adatokat,

Részletesebben

Felhasználói kézikönyv - Android kliens

Felhasználói kézikönyv - Android kliens Felhasználói kézikönyv - Android kliens Tartalom Telepítés Indítás Fő képernyők Térkép Rétegválasztó ablak Kilépés Keresés Lista Részletek Telepítés Az Élő Berek Android alkalmazás letölthető a www.e-berek.hu

Részletesebben

Irodából a terepre: a mobil informatika (alkalmazás bemutató)

Irodából a terepre: a mobil informatika (alkalmazás bemutató) Irodából a terepre: a mobil informatika (alkalmazás bemutató) Készítette: Dátum: Fűr Attila 2014.10.30. Bevezetés A mobilitás szerepe átértékelődik Gazdasági környezet változik: Válság, megszorítások kevesebb

Részletesebben

Kiskunmajsa és környéke turisztikai térinformatikai alkalmazás

Kiskunmajsa és környéke turisztikai térinformatikai alkalmazás Kiskunmajsa és környéke turisztikai térinformatikai alkalmazás Tartalomjegyzék 1. A RENDSZER RÖVID LEÍRÁSA...3 1.1. Elvárt funkciók:...3 1.2. Specifikáció...3 1.3. Funkciók ismertetése...3 2. RÉSZLETES

Részletesebben

Készítette: Enisz Krisztián, Lugossy Balázs, Speiser Ferenc, Ughy Gergely 2010.11.29. 1

Készítette: Enisz Krisztián, Lugossy Balázs, Speiser Ferenc, Ughy Gergely 2010.11.29. 1 Készítette: Enisz Krisztián, Lugossy Balázs, Speiser Ferenc, Ughy Gergely 2010.11.29. 1 /17 Tartalomjegyzék A térinformatikáról általánosságban Célok Felhasznált eszközök Fejlesztés lépései Adatbázis Grafikus

Részletesebben

IP Thermo for Windows

IP Thermo for Windows IP Thermo for Windows (2 db szenzorig ingyenes!) Klímafelügyelő és naplózó szoftver Az IP Thermo klímafelügyelő és naplózó szoftver szobák, épületek, irodák, szállodák teljes körű hőmérsékleti felügyeletére,

Részletesebben

III. Cím TÁJÉKOZTATÁS

III. Cím TÁJÉKOZTATÁS 21 III. Cím TÁJÉKOZTATÁS Az utastájékoztatási feladatokat a Szolgáltató látja el, továbbá gondoskodik arról, hogy az utasokat jogaikról, kötelezettségeikről, az igénybe vehető szolgáltatásokról tájékoztassa,

Részletesebben

Android Commander Felhasználói kézikönyv

Android Commander Felhasználói kézikönyv Android Commander Felhasználói kézikönyv Android Commander felhasználói kézikönyv A kézikönyv használata Mielőtt elindítaná és használná a szoftvert kérjük olvassa el figyelmesen a felhasználói kézikönyvet!

Részletesebben

minic studio Melinda Steel Weboldal kivitelezési árajánlat 2013.03.01.

minic studio Melinda Steel Weboldal kivitelezési árajánlat 2013.03.01. minic studio Melinda Steel Weboldal kivitelezési árajánlat 2013.03.01. Weboldal 1. Előkészítés 1.1. Anyaggyűjtés 1.2. Kutatás 2. Tervezés 3. Kivitelezés 3.1. Drótváz 3.2. Grafikus tervezés 3.3. Programozás

Részletesebben

TRBOnet Térinformatikai terminál és diszpécseri konzol

TRBOnet Térinformatikai terminál és diszpécseri konzol TRBOnet Térinformatikai terminál és diszpécseri konzol A TRBOnet egy kliens szerver diszpécser szoftver MOTOTRBO rádiók száméra. A TRBOnet szoftver jól alkalmazható a MOTOTRBO rádiós rendszereknél. A szoftver

Részletesebben

Sensor Technologies Kft. TrafficNET (közlekedés-információs rendszer)

Sensor Technologies Kft. TrafficNET (közlekedés-információs rendszer) TrafficNET (közlekedés-információs rendszer) 1 1. Projektcél A TrafficNet projekt célja olyan közlekedés-információs rendszer megvalósítása, amely Kecskeméten és vonzáskörzetében közlekedőket valósidejű

Részletesebben

Gépi tanulás a gyakorlatban. Bevezetés

Gépi tanulás a gyakorlatban. Bevezetés Gépi tanulás a gyakorlatban Bevezetés Motiváció Nagyon gyakran találkozunk gépi tanuló alkalmazásokkal Spam detekció Karakter felismerés Fotó címkézés Szociális háló elemzés Piaci szegmentáció analízis

Részletesebben

Helyzetalapú szolgáltatások közösségi hálózatokon. Helyzetalapú szolgáltatások

Helyzetalapú szolgáltatások közösségi hálózatokon. Helyzetalapú szolgáltatások közösségi hálózatokon MobileSocial A MobileSocial termék egy olyan mobil GIS alkalmazás platform kifejlesztéseként jött létre, mely social networking rendszerek adataiból építkezve képes aktív adatszolgáltatásra

Részletesebben

ADATÁTVITELI RENDSZEREK A GLOBÁLIS LOGISZTIKÁBAN

ADATÁTVITELI RENDSZEREK A GLOBÁLIS LOGISZTIKÁBAN 9. ELŐADÁS ADATÁTVITELI RENDSZEREK A GLOBÁLIS LOGISZTIKÁBAN A logisztikai rendszerek irányításához szükség van az adatok továbbítására a rendszer különböző elemei között. Ezt a feladatot a különböző adatátviteli

Részletesebben

Használati utasítás.

Használati utasítás. Lotus Notes Naptár Windows telefonra Használati utasítás. Írta: Varga Róbert 1 http://www.robertwpapps.uw.hu Bevezetés: Ezt az alkalmazást a fejlesztő saját használatra írta a teljesség igénye nélkül.

Részletesebben

Dropbox - online fájltárolás és megosztás

Dropbox - online fájltárolás és megosztás Dropbox - online fájltárolás és megosztás web: https://www.dropbox.com A Dropbox egy felhő-alapú fájltároló és megosztó eszköz, melynek lényege, hogy a különböző fájlokat nem egy konkrét számítógéphez

Részletesebben

KERÉKPÁRSZÁLLÍTÁS BUSZON, METRÓN, VILLAMOSON

KERÉKPÁRSZÁLLÍTÁS BUSZON, METRÓN, VILLAMOSON KERÉKPÁRSZÁLLÍTÁS BUSZON, METRÓN, VILLAMOSON Kerékpárszállítás buszon, metrón, villamoson Kovács Gergely COWI Magyarország Kft. # 2011.03.16. Jelenlegi helyzet Budapest fogaskerekű HÉV vasút # # # # #

Részletesebben

EDR. Az Országos Mentőszolgálatnál. EDR szerepe a mentésirányításban. Professzionális Mobiltávközlési Nap 2009 2009.04.08.

EDR. Az Országos Mentőszolgálatnál. EDR szerepe a mentésirányításban. Professzionális Mobiltávközlési Nap 2009 2009.04.08. EDR Az Országos Mentőszolgálatnál EDR szerepe a mentésirányításban.04.08. 1 Előzmények Az OMSZ két feltételhez kötötte az EDR használatát: Stabil működésű legyen az ország területét lefedő hálózat, ez

Részletesebben

Káity Károly forgalomfejlesztési és koordinációs igazgató

Káity Károly forgalomfejlesztési és koordinációs igazgató Forgalomirányítás és utastájékoztatás fejlesztése illetve üzemeltetési tapasztalatok a Dél-alföldi Régió VOLÁN társaságainál Káity Károly forgalomfejlesztési és koordinációs igazgató DAKK Dél-alföldi Közlekedési

Részletesebben

Markerek jól felismerhetőek, elkülöníthetők a környezettől Korlátos hiba

Markerek jól felismerhetőek, elkülöníthetők a környezettől Korlátos hiba 1. Ismertesse a relatív és abszolút pozíciómegatározás tulajdonságait, és lehetőségeit. Mit jelent a dead reckoning, és mi az odometria? Milyen hibalehetőségekre kell számítanunk odometria alkalmazásakor?

Részletesebben

GIS adatgyűjtés zseb PC-vel

GIS adatgyűjtés zseb PC-vel GIS adatgyűjtés zseb PC-vel Mit jelent a midas GIS kifejezés? Mapping Information Data Acquisition System Térképi Információ- és Adat Gyűjtő Rendszer Terepi adatgyűjtés a felhasználó által definiált adatbázisban.

Részletesebben

MOBILTRENDEK A SZÁLLÁSFOGLALÁSBAN

MOBILTRENDEK A SZÁLLÁSFOGLALÁSBAN MOBILTRENDEK A SZÁLLÁSFOGLALÁSBAN AZ MSZÉSZ XXXVIII. KÖZGYŰLÉSE HOTEL EGER PARK 2012.11.21. Gál Péter Tanácsadó BDO Magyarország Hotel és Ingatlan Szolgáltató Kft. TÉMÁK NEMZETKÖZI ÉS MAGYAR MOBILPENETRÁCIÓ,

Részletesebben

Általános tájékoztató szolgáltatások megrendeléséhez

Általános tájékoztató szolgáltatások megrendeléséhez Rólunk A dinamikusan fejlődő digitális könyvpiac egyre növekvő kulturális és gazdasági jelentősségre tesz szert. Az Egora Kiadó Kft. fő célkitűzése, hogy a hazai ügyfelek számára hatékony és elérhető megoldásokat

Részletesebben

Terepi adatgyűjtés mobil eszközökkel a természetvédelemben

Terepi adatgyűjtés mobil eszközökkel a természetvédelemben T E R M É S Z E T V É D E L E M Terepi adatgyűjtés mobil eszközökkel a természetvédelemben Dr. Takács András Attila Takács Gábor Biró Csaba Tartalom Bevezetés háttér információk GPS Természetvédelmi feladatok

Részletesebben

1000 felhasználó 15 országban

1000 felhasználó 15 országban Scolvo Control Scolvo termékeinkkel olyan mobil megoldásokat biztosítsunk ügyfeleink számára, melyek komoly értéket képviselnek a vállalati belső és külső folyamatok támogatásában, és hozzájárulnak a hatékonyabb

Részletesebben

Routing Útnyilvántartás iphone-hoz Felhasználói kézikönyv 2013 Bensoft

Routing Útnyilvántartás iphone-hoz Felhasználói kézikönyv 2013 Bensoft 1 Routing for iphone Routing Útnyilvántartás iphone-hoz Felhasználói kézikönyv 2013 Bensoft 2 Routing for iphone Tartalomjegyzék Első lépés beállítások... 3 Személyes adatok... 4 Cég adatok... 4 Gépkocsi

Részletesebben

TaxiLike használati bemutató Taxitársaságok és Taxisofőrök részére

TaxiLike használati bemutató Taxitársaságok és Taxisofőrök részére TaxiLike használati bemutató Taxitársaságok és Taxisofőrök részére 2012 09 03 Tartalom I. TaxiLike rövid bemutatás II. Első lépések Taxitársaság és Taxisofőrök részére III. TaxiLike Driver használata munka

Részletesebben

Digitális Szabadidő Térkép mobil és web alkalmazás Útmutató

Digitális Szabadidő Térkép mobil és web alkalmazás Útmutató Digitális Szabadidő Térkép mobil és web alkalmazás Útmutató A Digitális Szabadidő Térkép mobilalkalmazás a lovas illetve vízi túrázóknak fejlesztett alkalmazás, amely jelentősen megkönnyíti és a közösséghez

Részletesebben

Infrastrukturális vagy közösségi érzékelés. Vida Rolland, Fehér Gábor (BME TMIT) 2. Magyar Jövő Internet Konferencia 2015. november 11.

Infrastrukturális vagy közösségi érzékelés. Vida Rolland, Fehér Gábor (BME TMIT) 2. Magyar Jövő Internet Konferencia 2015. november 11. Infrastrukturális vagy közösségi érzékelés Vida Rolland, Fehér Gábor (BME TMIT) 2. Magyar Jövő Internet Konferencia 2015. november 11. Mitől okos a város? Érzékelés Feldolgozás / elemzés Sok szenzor sok

Részletesebben

Crossplatform mobil fejlesztőkörnyezet kiválasztását támogató kutatás

Crossplatform mobil fejlesztőkörnyezet kiválasztását támogató kutatás Crossplatform mobil fejlesztőkörnyezet kiválasztását támogató kutatás A Mobil multimédiás kliens fejlesztői eszközkészlet létrehozása című kutatás-fejlesztési projekthez A dokumentum célja A dokumentum

Részletesebben

Automatikus szivárgáskeresés Zajszint-adatgyűjtő hálózat korrelátoros funkcióval

Automatikus szivárgáskeresés Zajszint-adatgyűjtő hálózat korrelátoros funkcióval Automatikus szivárgáskeresés Zajszint-adatgyűjtő hálózat korrelátoros funkcióval Sebalog N-3 hálózat Aktuális mérési adatok minden nap Nincs szükség a loggerek helyszínen történő kiolvasására Távolról

Részletesebben

Routing for Android Bensoft 2013

Routing for Android Bensoft 2013 Bensoft 2013 Tartalomjegyzék Első lépés beállítások... 3 Személyes adatok... 4 Cég adatok... 4 Gépkocsi adatai... 6 Egyéb beállítások... 7 Ügyfél és iroda adatok... 8 Utazási okok... 9 Jelenlegi pozíció...

Részletesebben

Terepi adatfelvétel és geovizualizáció Androidos platformon

Terepi adatfelvétel és geovizualizáció Androidos platformon Terepi adatfelvétel és geovizualizáció Androidos platformon Balla Dániel 1 Kovács Zoltán 2 Varga Orsolya Gyöngyi 3 Zichar Marianna 4 5 1 PhD hallgató, Debreceni Egyetem Tájvédelmi és Környezetföldrajzi

Részletesebben

Mobilitás-utazási módok

Mobilitás-utazási módok Mobilitás-utazási módok Utazási igények oka. Területi munkamegosztás Fajlagos utazási igény Utazásra fordított idő-megtett távolság Mobilitás alakulása Utazási módok Egyéni közlekedés Időpont és útvonal

Részletesebben

Rónai Gergely. fejlesztési főmérnök BKK Közút Zrt.

Rónai Gergely. fejlesztési főmérnök BKK Közút Zrt. ITS fejlesztés Budapesten Rónai Gergely fejlesztési főmérnök BKK Közút Zrt. A fővárosi ITS kezdetei Nemzeti Közlekedési Napok 2013 - ITS fejlesztés Budapesten 2 ITS fejlesztések szervezeti háttere Budapest

Részletesebben

Tehergépjármű parkolás a hazai gyorsforgalmi úthálózaton Sándor Zsolt zsolt.sandor@mail.bme.hu

Tehergépjármű parkolás a hazai gyorsforgalmi úthálózaton Sándor Zsolt zsolt.sandor@mail.bme.hu Tehergépjármű parkolás a hazai gyorsforgalmi úthálózaton Sándor Zsolt zsolt.sandor@mail.bme.hu Budapesti Műszaki és Gazdaságtudományi Egyetem Közlekedésmérnöki és Járműmérnöki Kar Közlekedésüzemi és Közlekedésgazdasági

Részletesebben

Mobileye okostelefon alkalmazás

Mobileye okostelefon alkalmazás Mobileye okostelefon alkalmazás Használati útmutató 1. Bevezetés A Mobileye okostelefon alkalmazás olyan járművel csatlakoztatva működik, melybe telepítették a Mobileye 5 rendszert, hogy figyelmeztessen

Részletesebben

Az 1-es villamos Rákóczi hídon való meghosszabbításához kapcsolódó változásokról

Az 1-es villamos Rákóczi hídon való meghosszabbításához kapcsolódó változásokról Az 1-es villamos Rákóczi hídon való meghosszabbításához kapcsolódó változásokról 1) A társadalmi egyeztetésen meghirdetett javaslat A BKK 2014 nyarán megkezdte az 1-es villamosvonal Rákóczi hídon át, az

Részletesebben

Milenia Járműfigyelő Rendszer

Milenia Járműfigyelő Rendszer Milenia Járműfigyelő Rendszer Járműfigyelő rendszerünk mobil internet és műholdak segítségével nyújt felhasználóink számára magas színvonalú, valós idejű, járművek figyelésére kialakított szolgáltatást.

Részletesebben

Tájékoztató Új, utasbarát menetrend Dunaharaszti helyi közlekedésében

Tájékoztató Új, utasbarát menetrend Dunaharaszti helyi közlekedésében Tájékoztató Új, utasbarát menetrend Dunaharaszti helyi közlekedésében Tisztelt Utasaink! Örömmel értesítjük Önöket, hogy társaságunk 0. szeptember -től új menetrendet vezet be a dunaharaszti helyi autóbuszjáratokon.

Részletesebben

Symbian Nokia. A Symbian gyártója és a Nokia szabad forráskódúvá tette a Symbiant, így szabadon fejleszthetőek az applikációk a szoftverre.

Symbian Nokia. A Symbian gyártója és a Nokia szabad forráskódúvá tette a Symbiant, így szabadon fejleszthetőek az applikációk a szoftverre. Symbian Nokia Vodafone Magyarország zrt. 1096 Budapest, Lechner Ödön fasor 6. Nokia szolgáltatások, alkalmazások Nokia smartphone-okhoz: Az ovi.com Nokia okostelefonokhoz felépített, háttérszolgáltatást

Részletesebben

Katasztrófa menedzsment okostelefonon

Katasztrófa menedzsment okostelefonon Katasztrófa menedzsment okostelefonon Podolcsák Ádám adam.podolcsak@competterra.com Knyihár Zsuzsanna zsuzsanna.knyihar@competterra.com Compet-Terra Szervező és Tanácsadó Kft. www.competterra.com Megelőzhető

Részletesebben

INFORMATIKA ÁGAZATI ALKALMAZÁSAI. Az Agrármérnöki MSc szak tananyagfejlesztése TÁMOP-4.1.2-08/1/A-2009-0010

INFORMATIKA ÁGAZATI ALKALMAZÁSAI. Az Agrármérnöki MSc szak tananyagfejlesztése TÁMOP-4.1.2-08/1/A-2009-0010 INFORMATIKA ÁGAZATI ALKALMAZÁSAI Az Agrármérnöki MSc szak tananyagfejlesztése TÁMOP-4.1.2-08/1/A-2009-0010 13. GNSS mérés tervezése, végrehajtása Tervezés célja, eszközei, almanach GNSS tervező szoftverek

Részletesebben

Gyalogos elütések szimulációs vizsgálata

Gyalogos elütések szimulációs vizsgálata Gyalogos elütések szimulációs vizsgálata A Virtual Crash program validációja Dr. Melegh Gábor BME Gépjárművek tanszék Budapest, Magyarország Vida Gábor BME Gépjárművek tanszék Budapest, Magyarország Ing.

Részletesebben

Az élet, a telefonom és én. IpsosMobinauta

Az élet, a telefonom és én. IpsosMobinauta Az élet, a telefonom és én IpsosMobinauta Miről szól a kutatás? Hogy használják az okostelefont az emberek különböző napszakokban? Milyen érzelmek társulnak az okostelefonhoz? Megváltoztatta-e az okostelefon

Részletesebben

A vasút életéhez. Örvény-áramú sínpálya vizsgáló a Shinkawa-tól. Certified by ISO9001 SHINKAWA

A vasút életéhez. Örvény-áramú sínpálya vizsgáló a Shinkawa-tól. Certified by ISO9001 SHINKAWA SHINKAWA Certified by ISO9001 Örvény-áramú sínpálya vizsgáló a Shinkawa-tól Technikai Jelentés A vasút életéhez A Shinkawa örvény-áramú sínpálya vizsgáló rendszer, gyors állapotmeghatározásra képes, még

Részletesebben

SZOLGÁLATI TITOK! KORLÁTOZOTT TERJESZTÉSŰ!

SZOLGÁLATI TITOK! KORLÁTOZOTT TERJESZTÉSŰ! A 10/2007 (II. 27.) SzMM rendelettel módosított 1/2006 (II. 17.) OM rendelet Országos Képzési Jegyzékről és az Országos Képzési Jegyzékbe történő felvétel és törlés eljárási rendjéről alapján. Szakképesítés,

Részletesebben

Rallyinfo.hu - GPS rendszer működésének technikai leírása V1

Rallyinfo.hu - GPS rendszer működésének technikai leírása V1 Rallyinfo.hu - GPS rendszer működésének technikai leírása V1 1. ábra: GPS doboz Méretei: 115x90x55mm Súlya: 340g + 2db csőbilincs 110g GPS mérés általános működési elve: A GPS egy fejlett helymeghatározó

Részletesebben

Közúti forgalomszámlálás e_sensor rendszerrel. 2012.06.04 2012.06.10 Budapest dugódíj projekt (sajtóanyag)

Közúti forgalomszámlálás e_sensor rendszerrel. 2012.06.04 2012.06.10 Budapest dugódíj projekt (sajtóanyag) Közúti forgalomszámlálás e_sensor rendszerrel 2012.06.04 2012.06.10 Budapest dugódíj projekt (sajtóanyag) 1 Cégbemutató A Sensor Technologies Kft. videó analitikai rendszereket fejleszt budapesti székhellyel.

Részletesebben

Android Commander Felhasználói kézikönyv

Android Commander Felhasználói kézikönyv Android Commander Felhasználói kézikönyv A kézikönyv használata Mielőtt elindítaná és használná a szoftvert kérjük olvassa el figyelmesen a felhasználói kézikönyvet! A dokumentum nem sokszorosítható illetve

Részletesebben

Rendszám felismerő rendszer általános működési leírás

Rendszám felismerő rendszer általános működési leírás Rendszám felismerő rendszer általános működési leírás Creativ Bartex Solution Kft. 2009. A rendszer funkciója A rendszer fő funkciója elsősorban parkolóházak gépkocsiforgalmának, ki és beléptetésének kényelmesebbé

Részletesebben

mindennapi közlekedési mód népszerűsítése

mindennapi közlekedési mód népszerűsítése Szuppinger Péter REC 2013.05.08. Szentendre Integrált közlekedéstervezés és a kerékpározás Miért integrált? Cél: Miért kerékpározás, integrált? mint mindennapi közlekedési mód népszerűsítése Tapasztalat:

Részletesebben

SWS 500 HU FELHASZNÁLÓI KÉZIKÖNYV. Megjegyzés: A mobiltelefon nem tartozék.

SWS 500 HU FELHASZNÁLÓI KÉZIKÖNYV. Megjegyzés: A mobiltelefon nem tartozék. SWS 500 HU FELHASZNÁLÓI KÉZIKÖNYV Megjegyzés: A mobiltelefon nem tartozék. ELSŐ LÉPÉSEK A csomag tartalma: SWS 500 hő- és páratartalom-érzékelő Felhasználói kézikönyv 2x 1,5 V AA típusú elem (alkáli) Az

Részletesebben

A 15-ös, 115-ös és 133-as autóbuszjáratok átalakítása

A 15-ös, 115-ös és 133-as autóbuszjáratok átalakítása A 15-ös, 115-ös és 133-as autóbuszjáratok átalakítása 1) A társadalmi egyeztetésen meghirdetett javaslatok A BKK Zrt. kikérte utasai véleményét a 15-ös, 115-ös és 133-as viszonylatok közlekedési rendjének

Részletesebben

Alter Róbert Báró Csaba Sensor Technologies Kft

Alter Róbert Báró Csaba Sensor Technologies Kft Közúti forgalomelemzés kamerával e_traffic Alter Róbert Báró Csaba Sensor Technologies Kft Előadás témái Cégbemutató Videó analitikai eljárások Forgalomszámláló eszközök összehasonlítása e_traffic forgalomelemző

Részletesebben

Informatika Budapest közlekedésében

Informatika Budapest közlekedésében Informatika Budapest közlekedésében Fejlesztések és megtakarítás Balatonfüred, 2011. november 23. Vitézy Dávid vezérigazgató Budapesti Közlekedési Központ 2 Tartalomjegyzék A BKK feladatai, struktúrája.

Részletesebben

FŐBB MEGVALÓSÍTÁSOK ÉS BERUHÁZÁSOK A 2006-2011 KÖZÖTTI IDŐSZAKBAN

FŐBB MEGVALÓSÍTÁSOK ÉS BERUHÁZÁSOK A 2006-2011 KÖZÖTTI IDŐSZAKBAN FŐBB MEGVALÓSÍTÁSOK ÉS BERUHÁZÁSOK A 2006-2011 KÖZÖTTI IDŐSZAKBAN 2006 5 évre szóló bérleti szerződéssel két jegyautomatát szereztünk be amelyek a a Szabó Kati Sportcsarnok és a Lábasház megállóhelyeknél

Részletesebben

Gyakorlati vizsgatevékenység A

Gyakorlati vizsgatevékenység A Gyakorlati vizsgatevékenység A Szakképesítés azonosító száma, megnevezése: 481 04 0000 00 00 Web-programozó Vizsgarészhez rendelt követelménymodul azonosítója, megnevezése: 1189-06 Web-alkalmazás fejlesztés

Részletesebben

A DLD használatának feltételei:

A DLD használatának feltételei: A DLD használatának feltételei: DLD Short Range DLD Wide Range Egy WLAN kapcsolattal rendelkező irodai számítógép Egy folyamatos internetkapcsolattal rendelkező irodai számítógép Egy, a számítógéphez csatlakoztatott

Részletesebben

Zimbra levelező rendszer

Zimbra levelező rendszer Zimbra levelező rendszer Budapest, 2011. január 11. Tartalomjegyzék Tartalomjegyzék... 2 Dokumentum információ... 3 Változások... 3 Bevezetés... 4 Funkciók... 5 Email... 5 Társalgás, nézetek, és keresés...

Részletesebben

MOBIL PLATFORMHÁBORÚ. Török Gábor

MOBIL PLATFORMHÁBORÚ. Török Gábor MOBIL PLATFORMHÁBORÚ Török Gábor Szabad Szoftver Konferencia, 2010 Tartalom Bevezetés A mobilpiacról Mobil platformok Fejlesztői szemszögből A nyíltság szintjei Történelmi áttekintés Mérföldkövek: mobil

Részletesebben

Térinformatikai DGPS NTRIP vétel és feldolgozás

Térinformatikai DGPS NTRIP vétel és feldolgozás Térinformatikai DGPS NTRIP vétel és feldolgozás Méréseinkhez a Thales Mobile Mapper CE térinformatikai GPS vevıt használtunk. A mérést a Szegedi Tudományegyetem Egyetem utcai épületének tetején található

Részletesebben

Örülök, hogy felkeltette érdeklődésedet ez a kísérlet, először is szeretném megköszönni, hogy időt szánsz rá!

Örülök, hogy felkeltette érdeklődésedet ez a kísérlet, először is szeretném megköszönni, hogy időt szánsz rá! Kedves Tesztelő! Örülök, hogy felkeltette érdeklődésedet ez a kísérlet, először is szeretném megköszönni, hogy időt szánsz rá! Alföldy-Boruss András vagyok, 28 éves, főállásomban elemző menedzser vagyok

Részletesebben

ITS fejlesztések Pécs közösségi közlekedésében

ITS fejlesztések Pécs közösségi közlekedésében 1 Pécs, 2013. május 23. ITS fejlesztések Pécs közösségi közlekedésében 1 / Tartalom Az előadás során érintett témakörök: 1. Az ITS Master Plan szerepe a városoknál 2. BRT Bus Rapid Transit, közösségi közlekedés

Részletesebben

Vezetői információs rendszerek

Vezetői információs rendszerek Vezetői információs rendszerek Kiadott anyag: Vállalat és információk Elekes Edit, 2015. E-mail: elekes.edit@eng.unideb.hu Anyagok: eng.unideb.hu/userdir/vezetoi_inf_rd 1 A vállalat, mint információs rendszer

Részletesebben

Scolvo Multi-Unit Retail Management App MURMA

Scolvo Multi-Unit Retail Management App MURMA Scolvo Multi-Unit Retail Management App MURMA Scolvo termékeinkkel olyan mobil megoldásokat biztosítsunk ügyfeleink számára, melyek komoly értéket képviselnek a vállalati belső és külső folyamatok támogatásában,

Részletesebben

GCF 1.1 Gas Consumption Forecast

GCF 1.1 Gas Consumption Forecast GCF 1.1 Gas Consumption Forecast A szabadpiaci gáz-kereskedelem alapja a forrás- és a fogyasztói oldali menetrendek tervezése, operatív levezénylése és elszámolása. Az energia kereskedelem a jövõre vonatkozik,

Részletesebben

TERC V.I.P. hardverkulcs regisztráció

TERC V.I.P. hardverkulcs regisztráció TERC V.I.P. hardverkulcs regisztráció 2014. második félévétől kezdődően a TERC V.I.P. költségvetés-készítő program hardverkulcsát regisztrálniuk kell a felhasználóknak azon a számítógépen, melyeken futtatni

Részletesebben

3D - geometriai modellezés, alakzatrekonstrukció, nyomtatás

3D - geometriai modellezés, alakzatrekonstrukció, nyomtatás 3D - geometriai modellezés, alakzatrekonstrukció, nyomtatás 15. Digitális Alakzatrekonstrukció Méréstechnológia, Ponthalmazok regisztrációja http://cg.iit.bme.hu/portal/node/312 https://www.vik.bme.hu/kepzes/targyak/viiiav54

Részletesebben

OZEKI Phone System. A jövő vállalati telefon rendszerének 4 alappillére. A jövő üzleti telefon rendszere SMS. Mobil mellékek. Összhang az IT-vel

OZEKI Phone System. A jövő vállalati telefon rendszerének 4 alappillére. A jövő üzleti telefon rendszere SMS. Mobil mellékek. Összhang az IT-vel A jövő üzleti telefon rendszere A jövő vállalati telefon rendszerének 4 alappillére SMS Mobil mellékek Webtelefon Üzenetküldés Összhang az IT-vel É rdemes elolvasni! Ajánlatkérés Kérem, töltse ki az űrlapot,

Részletesebben