Souhrnná metodika pro implementaci algoritmu pro stanovení

Dopravní studie:
Souhrnná metodika pro implementaci algoritmu pro stanovení
jízdních dob na základě dostupných dat z plovoucích vozidel
výzkumná zpráva č.: 49
Tato práce byla podpořena grantem Studentské grantové
soutěže ČVUT č. SGS15/105/OHK2/1T/16
Řešitelé:
Ing. Přemysl Derbek, Ph.D.
Bc. Jana Blümelová
Ing. Ivan Boyarkin
Ing. Jiří Růžička
Dopravní studie:
Souhrnná metodika pro implementaci algoritmu pro
stanovení jízdních dob na základě dostupných dat z
plovoucích vozidel
výzkumná zpráva č.: 49
Tato práce byla podpořena grantem Studentské grantové soutěže ČVUT č.
SGS15/105/OHK2/1T/16.
2015
České vysoké učení technické v Praze
Fakulta dopravní
Ústav dopravní telematiky
Konviktská 20, Praha1, 110 00
2
Obsah
Obsah .......................................................................................................................................... 3
Seznam použitých pojmů a zkratek ............................................................................................ 4
1.
Základní přístupy ke stanovení jízdních dob ...................................................................... 5
2.
Analýza dostupných FCD dat ............................................................................................ 6
3.
Zpracování dostupných dat ................................................................................................. 8

Obecný proces predikce .................................................................................................. 8

Metodiky mapování v projektu ....................................................................................... 8

Predikční techniky ......................................................................................................... 10
4.
Implementace algoritmu ................................................................................................... 12

Proces zaznamenávání dat ............................................................................................. 13

Proces generování mapy................................................................................................ 14

Proces vykreslování dat ................................................................................................. 15

Použitý software ............................................................................................................ 15

Kalibrace modelu na základě vzniklých podnětů .......................................................... 15

Dopravní aplikace ......................................................................................................... 16
Prezentace výsledků .......................................................................................................... 18
5.
6.

Konference .................................................................................................................... 18

Webová aplikace ........................................................................................................... 18

Původní mobilní aplikace pro Android ......................................................................... 19

Výstup pro PIT .............................................................................................................. 19
Použitá literatura a odkazy na použitý software ............................................................... 20
3
Seznam použitých pojmů a zkratek
Azimut - celočíselný údaj určující aktuální výchylku směru vozidla od severního směru (0°
nebo 360° - sever, 90° - východ, 180° - jih, 270°- západ)
Dílčí úsek - jednotlivé části složených křivek (way). Dílčí úseky jsou definovány dvojicí bodů
𝐴 a 𝐵 se souřadnicemi 𝐴𝑥 , 𝐴𝑦 a 𝐵𝑥 , 𝐵𝑦 .
Floating car data -FCD - data z plovoucích vozidel, tzn. data z vozidel vybavených GNSS
přijímačem
GeoJSON - formát pro kódování geografických datových struktur
Hláška - předem definovaný soubor dat získaný z vozidla vybaveného GNSS přijímačem
ID vozidla -anonymní a jedinečný identifikátor vozidla
Jízdní doba - časový úsek pro překonání vzdálenosti v prostoru mezi dvěma definovanými
body
JSON - datový formát určený pro přenos dat, která mohou být organizována v polích nebo
agregována v objektech
Klíč MD5- jedna ze série kryptografických hašovacích funkcí, sloužící pro kontrolu integrity
souborů
Layer - vrstva mapy v navržené webové aplikaci
Mapový podklad -mapa použitá jako grafický podklad pro odvození jiné mapy téhož druhu
nebo mapa, jejíž obsah je podkladem pro lokalizaci tematických jevů
Mezikřižovatková složená křivka - složená křivka vytvořená z důvodu vývojářsky
nepřívětivé definice složených křivek, jedná se o úsek mezi dvěma křižovatkami
Neobsazený úsek - úsek, z něhož nebyla po definovaný čas přijata žádná hláška
OSM - OpenStreetMap je projekt, jehož cílem je tvorba volně dostupných geografických dat
a následně jejich vizualizace do podoby topografických map
PIT - Proměnná informační tabule určena k poskytování dopravních informací
Platné složené křivky (way) - vybrané složené křivky (way), které jsou po filtraci ukládány
do databáze
Pražský okruh - ekvivalent pro Silniční okruh kolem Prahy
Preprocessing - český ekvivalent pro předzpracování
Přiřazení hlášky - konfrontace přijaté hlášky se silniční sítí v databázi s následným určením
příslušnosti k úseku
Shift - posun zobrazených way vpravo ve směru jízdy z důvodu uživatelsky přívětivějšího
zobrazení mapy
Složená křivka (way) - uspořádaný seznam uzlů definovaný v OSM, obsahující vždy několik
dílčích úseků
Tag - označení (příznak) pro určitou skupinu dat
Timestamp - časová značka - informace o čase výskytu události, v projektu konkrétně přijetí
hlášky z vozidla
4
1. Základní přístupy ke stanovení jízdních dob
Predikce jízdních dob pro silniční síť je důležitou součástí dnešních navigačních systémů.
Informace o jízdní době a následná optimální reakce účastníků silničního provozu na
poskytnutou informaci mohou vést k celkové větší efektivitě dopravy. Pro predikci jízdních
dob existují dva základní přístupy:


použití stacionárních senzorů (indukční smyčkové detektory, videodetekce)
využití dat z plovoucích vozidel (Floating Car Data - FCD)
V prvním případě senzory poskytují informaci o základních charakteristikách dopravního
proudu v pravidelných intervalech pro daný silniční úsek.
Druhým přístupem je využití dat z plovoucích vozidel, což jsou v případě výzkumné činnosti
stopy GNSS pozice. V ideálním případě plovoucí vozidla poskytují data o počtu
předjížděných a předjíždějících vozidel, ze kterých je možno vypočítat intenzitu dopravy a
průměrnou rychlost, a dále s použitím vhodného matematického aparátu i stanovit úroveň
kvality dopravy. Množství dopravních prostředků, které jsou schopné naměřit výše uvedené
hodnoty je ale téměř zanedbatelné. I proto je v předkládaném výzkumu pracováno výhradně s
údaji o poloze vozidla v čase. Hlavní výhodou plovoucích vozidel oproti stacionárním
senzorům je, že jsou schopny poskytovat informace z celé silniční sítě. Jako nevýhodu je
naopak možné zmínit, že data z plovoucích automobilů se vyskytují v nepravidelných
intervalech a jsou obvykle mnohem méně frekventovaná pro konkrétní silniční úsek. To v
praxi znamená, že pro konkrétní silniční úsek nemusí být známy žádná FCD data.
5
2. Analýza dostupných FCD dat
V projektu bylo pracováno s dvěma typy FCD dat:


historická data z Pražského okruhu z období let 2012 –2014
data z vlastní vyvinuté mobilní aplikace z období září 2015 – prosinec 2015
Na základě původního předpokladu byla v první fázi projektu využita pouze historická data.
Zdrojem dat je komerční flotila vozidel sledovaná společností zabývající se zabezpečením a
vyhledáváním vozidel. Data byla poskytnuta s laskavým svolením Ústavu dopravní
telematiky, Fakulty dopravní, ČVUT, na jehož půdě je tento výzkum vypracováván.
Data jsou poskytnuta v 15 souborech ve formátu CSV, každý soubor obsahuje cca 3-6 milionů
záznamů a zároveň reprezentuje 1 měsíc nasbíraných dat. Každý záznam se skládá z
následujících částí.







ID vozidla - anonymní a jedinečný identifikátor vozidla, který zůstává neměnný v
průběhu jednoho kalendářního měsíce, v dalším měsíci je vozidlu přiřazen jiný
identifikátor. Jedná se o celočíselný údaj.
Poloha vozidla - souřadnice ve formátu WGS84 se skládá ze dvou složek - zeměpisné
šířky a zeměpisné délky, souřadnice je udávána s přesností na pět desetinných míst.
Aktuální rychlost vozidla - celočíselný údaj v km/h.
Čas vyslání dat - údaj ve formátu DD.MM.RRRR hh:mm.ss
Azimut - celočíselný údaj určující aktuální výchylku směru vozidla od severního
směru (0° - sever, 90° - východ, 180° - jih, 270°- západ)
Klíček v zapalování - indikuje přítomnost klíčku v zapalování, kde ON - klíček je v
zapalování, OFF - klíček není v zapalování.
Typ vozidla - rozděluje vozidla do dvou kategorií, kde OA - osobní automobil, NA nákladní automobil.
ID
zařízení
Zem.
šířka
Zem. délka
Rychlost
Čas vyslání dat
Azimut
Klíček
Typ
vozidla
672384
50.09218
14.2957
69
1.8.2012 1:01:22
183
ON
NA
672384
50.08888
14.2956
85
1.8.2012 1:01:35
185
ON
NA
672384
50.08634
14.2949
85
1.8.2012 1:01:47
187
ON
NA
672384
50.08634
14.2949
85
1.8.2012 1:01:56
187
ON
NA
672384
50.07854
14.29208
86
1.8.2012 1:02:09
204
ON
NA
672384
50.07489
14.28947
87
1.8.2012 1:02:20
211
ON
NA
672384
50.07258
14.28728
87
1.8.2012 1:02:30
215
ON
NA
Obrázek 1 Příklad dostupných dat
6
Jednotlivé záznamy z vozidel byly přenášeny pomocí datových služeb mobilního operátora a
dále po síti do výpočetního centra společnosti. Atributy indikující přítomnost klíčku v
zapalování a typ vozidla nejsou pro FCD typické, ale vyplývají z povahy společnosti, která s
těmito daty pracuje. Slouží k bezpečnostním účelům, neboť umožňují určit, zda je s vozidlem
manipulováno bez zažehnutého motoru.
Doprava na Pražském okruhu má dosti specifický charakter, který se velmi liší od charakteru
dopravy v centru metropole. V zájmu větší universálnosti navrženého řešení byla vytvořena
jednoduchá mobilní aplikace, sbírající data z projetých úseků jiných částí Prahy. Nasbíraná
data z mobilní aplikace byla rovněž využita a na základě nich došlo ke kalibraci původního
modelu založeného pouze na historických datech z Pražského okruhu. Data jsou nasbírána z
vlastního vozidla jednoho z řešitelů, především z oblasti Prahy 8, Prahy 9 a Prahy 6. Pro
podrobnější a složitější charakter dopravy v posuzované oblasti vzniklo v průběhu řešení
projektu několik zajímavých podnětů ke kalibraci modelu, které budou podrobněji vysvětleny
v kapitole 4. Data z mobilní aplikace jsou téměř ve stejném tvaru jako původně použitá
historická data z Pražského okruhu. Navíc se v nich objevuje pouze informace, zda se
jednotlivé hlášky dat podařilo odeslat správně či nikoliv.
7
3. Zpracování dostupných dat
 Obecný proces predikce
Kompletní obecný proces predikce jízdních dob s pomocí FCD dat se skládá z několika
důležitých dílčích a na sebe navazujících podprocesů [1] znázorněných na Obrázku 2.
Obrázek 2 Schéma obecného procesu predikce [1]
Sběr FCD dat je ve výzkumné činnosti zajištěn simulací historických záznamů a dále
získáváním nových záznamů prostřednictvím mobilní aplikace. Pro simulaci historických
záznamů byla vyvinuta vlastní mobilní aplikace.
Dle dostupných zdrojů obecně neexistuje jednotný přístup k předzpracování FCD dat, neboť
vždy záleží na konkrétních případech pro konkrétní data. Nejčastěji se při práci s FCD
můžeme setkat s těmito nedostatky [2]:




Chyba lokace (V datech se objevují body, které jsou příliš vzdáleny od zkoumaného
úseku komunikace. Taková data by měla být odstraněna)
Chybějící nebo zkreslená data pod mosty, v tunelech nebo v uličním kaňonu, kde
GNSS přijímače nemohou přijímat satelitní signál.
Hlášky příliš pomalých nebo příliš rychlých vozidel (Rychlost chybových vozidel je
mnohem větší/menší než rychlost většiny nejrychlejších/nejpomalejších vozidel
okolního dopravního proudu.)
Data o pozici jsou předávaná v systému WGS84, a silniční síť je často prezentována
pomocí jiného souřadnicového systému. (Řešením je nalezení vhodné transformace
souřadnic pro oba systémy)
Předzpracováním FCD dat se tedy rozumí jednak filtrace vzhledem k logicky nereálným
hodnotám, ale i filtrace vzhledem k mapovému podkladu.
V podprocesu mapování jsou stěžejními body zájmu zejména odhad polohy vozidla vzhledem
silniční síti a zaznamenávání rychlosti na příslušném silničním úseku.
Použitím vhodné predikční techniky je pak možné dosáhnout hlavních cílů výzkumné
činnosti, tj. vizuálního zobrazení aktuálního stavu dopravy za posledních 10 minut, výpočtu
jízdní doby mezi klíčovými body pro PIT a teoretickému výpočtu jízdní doby mezi body
definovanými uživatelem.
 Metodiky mapování v projektu
Po přijetí hlášky do systému je zařízení dle pozice přiřazeno k mapovému podkladu.
Mapovým podkladem, který je využit v rámci výzkumné činnosti, je mapa hlavního města
Prahy ze serveru OpenStreetMaps (OSM), a to zejména z důvodu volné využitelnosti pod
otevřenou licencí.
8
Hranice Prahy použité v projektu vychází z tagu: 𝑏𝑜𝑢𝑛𝑑𝑎𝑟𝑦 = 𝑎𝑑𝑚𝑖𝑛𝑖𝑠𝑡𝑟𝑎𝑡𝑖𝑣𝑒, značení v
mapě pak reflektuje normu ISO 3166-2-CZ-PR. Z OSM jsou do vytvořené databáze
nahrávány složené křivky (tzv. WAY), ty jsou v OSM definovány jako posloupnosti bodů. V
Každé této křivce jsou definovány z důvodu urychlení přiřazení hlášek dílčí úseky mezi
každou dvojicí sousedních bodů 𝐴 a 𝐵 se souřadnicemi 𝐴𝑥 , 𝐴𝑦 a 𝐵𝑥 , 𝐵𝑦 .
V následujícím výpočtu je pracováno s geometrickými útvary s uvedeným významem:





bod A - označuje polohu začátku úseku
bod B - označuje polohu konce úseku
bod C - označuje polohu hlášky
vzdálenost c - označuje délku úseku
vzdálenost d - označuje vzdálenost úseku c od bodu C
Vzdálenosti 𝑎, 𝑏,𝑐 mezi body 𝐴,𝐵 a 𝐶 v trojrozměrném prostoru jsou počítány pomocí křivky
na kouli, resp. geoidu (Obrázek 3) dle podrobně popsaného návodu v [3]:
Obrázek 3Výpočet vzdálenosti bodu od úseku [17]
Na vzniklý trojúhelník je dále nahlíženo jako na dvourozměrnou plochu. Jedná se tedy o
jistou formu aproximace, která je ovšem pro požadovanou přesnost naprosto dostačující.
Vzdálenost 𝑑 mezi bodem 𝐶 a úsekem 𝐴𝐵 je stanovena jako výška na základnu 𝑐 za
předpokladu, že žádný z úhlů trojúhelníku není tupý. Níže je k nalezení postup pro výpočet
vzdálenosti 𝑑:


Pokud 𝛼 ≥ 90° =>𝑑 = 𝐴𝐶
Pokud 𝛽 ≥ 90° =>𝑑 = 𝐵𝐶

Jinak: 𝑑 =
2∙
𝑠−𝑎 𝑠−𝑏 𝑠−𝑐
𝑐
, kde 𝑠 =
𝑎+𝑏+𝑐
2
V souvislosti se zjištěním v průběhu kalibrace modelu, že základní mapa s definicemi
elementů vycházejícími z OSM je pro vlastní řešení projektu nedostačující, je současně
9
vytvářena vlastní mapa s mezikřižovatkovými složenými křivkami, tzn., že každá složená
křivka je v místě setkání s jinou složenou křivkou rozdělena tak, aby se složené křivky
neprotínaly v jiném místě než v počátečním nebo koncovém bodě. Následně je celá mapa
uložena do paměti a pomocí tzv. transakce je dále uložena do databáze, což umožňuje
průběžnou aktualizaci mapy bez nutnosti pozastavení činnosti.
 Predikční techniky
V rámci rešerše projektu bylo nalezeno několik základních predikčních technik pro stanovení
jízdních dob. Níže je k vidění jejich soupis a nejčastější způsob jejich využití. Bližší
informace o jednotlivých jsou k dispozici v uvedených zdrojích.

Kalmanův Filtr [4]
Aplikace Kalmanova filtru je vhodná v mnoha případech, nejčastěji však ve dvou kategoriích,
kterými jsou predikce a výkonová analýza prediktorů. Kalmanův filtr umožňuje předpovídat
stavy proměnných, tedy i např. jízdní doby. Průměrná jízdní doba označených vozidel v
každém časovém intervalu je považována za pravdivou hodnotu k predikci následující
hodnoty v budoucnosti.

Support Vector Machine Reggresion [5]
Support Vector Machine (SVM) je moderní technikou, která nedávno nabyla na důležitosti v
oblasti strojového učení a klasifikace vzorů (patternrecognition).V úloze klasifikace SVM
hledá nadrovinu, která v prostoru příznaků optimálně rozděluje trénovací data.[8] se zabývá
použitím 3-vstupové SVM regrese za účelem odhadu budoucí jízdní doby.

Ridge Regression [6]
V češtině známá pod pojmem: "Hřebenová regrese." Zabývá se problematikou
multikolinearity. O multikolinearitě hovoříme tehdy, pokud má regresní matice lineárně
závislé sloupce.

Travel Time Median Backprojection [6]
Další obecnou technikou používanou k odhadu jízdních dob je zpětná projekce jízdních dob
napříč každým úsekem.

Odhad jízdní doby na základě střední rychlosti [7]
Modifikace této techniky popsané podrobněji v nalezeném zdroji byla řešitelským týmem
zvolena pro vývoj vlastního algoritmu. Níže je k nalezení obecný postup výpočtu jízdních dob
na základě střední rychlosti, který se skládá z výpočtu střední rychlosti vozidla, výpočtu
střední rychlosti na daném úseku a výpočtu odhadu jízdní doby na dané trase.
1. Výpočet střední rychlosti vozidla
Střední rychlost 𝒖𝒊𝒋 j-tého vozidla na i-tém úseku se vypočte dle vzorce:
10
𝟏
𝒖𝒊𝒋 =
𝒎
𝒎
𝒗𝒊𝒋𝒌
𝒌=𝟏
𝑢𝑖𝑗
střední rychlost j-tého vozidla na i-tém úseku
𝑚
počet hlášek (údajů) z j-tého vozidla
𝑣𝑗𝑘𝑖
jednotlivé hlášky - rychlosti vozidla
2. Výpočet střední rychlosti na daném úseku
Střední rychlost na daném úseku lze získat jako harmonický průměr jednotlivých středních
rychlostí všech vozidel.
𝒏
𝒖𝒊 =
𝒏
𝒌=𝟏 𝒖𝒊𝒋
𝑢𝑖𝑗
střední rychlost j-tého vozidla na i-tém úseku
𝑛
počet vozidel, která projela posuzovaným úsekem 𝑖
𝑢𝑖
střední rychlost na i-tém úseku
3. Výpočet odhadu jízdní doby na trase
Odhadnutá jízdní doba na trase 𝑒 se počítá jako suma podílu střední rychlosti a délky všech
úseků, z nichž se trasa 𝑒 skládá.
𝑛
𝑡𝑒 =
𝑖=1
11
𝑙𝑖
𝑢𝑖
4. Implementace algoritmu
V rámci výzkumné činnosti nedochází k vymazávání starších historických dat. Teoreticky
může docházet k promazávání dat na základě jakýchkoliv podmínek vůči času. Po přiřazení
hlášek k mapovému podkladu je pomocí hlášek uložených do databáze vypočítána průměrná
rychlost pro jednotlivé dílčí úseky složené křivky. S obousměrností komunikací se řešitelský
tým vypořádal zavedením dvou azimutů a dvou průměrných rychlostí pro každý obousměrný
úsek.
Průměrná rychlost na úseku je počítána jako průměr ze součtu rychlostí zaznamenaných
plovoucími vozidly navýšeného o rychlosti virtuálních vozidel.
𝑣𝑎𝑣 𝑔 𝑢𝑠𝑒𝑘𝑢
1
=
𝑚
𝑚
𝑣𝑖
𝑖=1
pro 𝑚 hlášek na úseku
Výpočet průměrné rychlosti složené křivky zohledňuje maximální povolenou rychlost na
úsecích. To je nutné zejména pro filtraci v případě nedostatečného počtu vozidel na úseku
nebo s rychlostí nevypovídající okolnímu dopravnímu proudu. Bez řádného zohlednění
maximální povolené rychlosti by aplikace mohla vyhodnotit dopravní kongesci na trase, kde
by se tato reálně vůbec nemusela vyskytovat.Z tohoto důvodu je navržen systém, který
zohledňuje rychlost na základě počtu bodů odpovídajících dané složené křivce.
1. Načtení unikátních ID úseků z tabulky TEMP, do které se ukládají hlášky
vozidel
2. Výběr z tabulky SECTIONS obsahující dílčí úseky na základně unikátních ID
úseků
3. Vytvoření šablony složených křivek (way)
𝑊𝐴𝑌[: 𝑎𝑚𝑜𝑢𝑛𝑡] = 𝑝𝑜č𝑒𝑡_𝑏𝑜𝑑ů
𝑊𝐴𝑌[: 𝑠𝑢𝑚𝑠𝑝𝑒𝑒𝑑 ] = 𝑎𝑚𝑜𝑢𝑛𝑡 ∗ 𝑚𝑎𝑥_𝑠𝑝𝑒𝑒𝑑
Šablona složených křivek obsahuje informaci o počtu hlášek. Na začátku
předpokládáme, že ve složené křivce je takový počet hlášek, který odpovídá počtu
bodů (𝑎𝑚𝑜𝑢𝑛𝑡) v dané složené křivce. Tento krok je nutný za účelem filtrování dat.
Součtová rychlost 𝑠𝑢𝑚_𝑠𝑝𝑒𝑒𝑑 vznikne vynásobením počtu bodů ve složené křivce a
maximální povolené rychlosti dané složené křivky 𝑚𝑎𝑥_𝑠𝑝𝑒𝑒𝑑.
4. Sečtení reálných vozidel a imaginárních vozidel ze šablony
Hodnoty každého dílčího úseku z výběru v bodě 2 přičteme k odpovídajícím
hodnotám mezikřižovatkové složené křivky, které přísluší daný úsek:
𝑊𝐴𝑌 𝑠𝑢𝑚_𝑠𝑝𝑒𝑒𝑑 += 𝑆𝐸𝐶𝑇𝐼𝑂𝑁 𝑠𝑢𝑚_𝑠𝑝𝑒𝑒𝑑
𝑊𝐴𝑌 𝑎𝑚𝑜𝑢𝑛𝑡 += 𝑆𝐸𝐶𝑇𝐼𝑂𝑁[𝑎𝑛𝑜𝑢𝑛𝑡]
12
 Proces zaznamenávání dat
Kompletní proces zaznamenávání dat se skládá z několika po sobě jdoucích dílčích kroků:
1. Kontrola hlášky- V prvním kroku je zkontrolováno, zda hláška obsahuje všechny
požadované parametry, konkrétně klíč MD5 z MAC adresy, zeměpisnou šířku a délku,
rychlost vozidla, azimut. V okamžiku obdržení hlášky je k této přiřazena časová
značka.
Příklad správného tvaru hlášky:
/𝑟𝑒𝑝𝑜𝑟𝑡? 𝑙𝑎𝑡 = 50.118248&𝑙𝑜𝑛 = 14.492427&𝑣 = 50&𝑎𝑧 = 90&𝑘𝑒𝑦 = 528𝑐8𝑒6𝑐𝑑4𝑎3𝑐6598999𝑎0𝑒9𝑑𝑓15𝑎𝑑32
𝑙𝑎𝑡, 𝑙𝑜𝑛 – poloha vozidla: zeměpisná šířka, resp. délka
𝑣 – rychlost vozidla
𝑎𝑧 – azimut vozidla
𝑘𝑒𝑦 – identifikační klíč vozidla
2. Kontrola hranice mapy - Je zkontrolováno, zda příslušná hláška leží uvnitř hranic
zkoumané oblasti Prahy (viz kapitola Metodiky mapování v projektu).
3. Výpočet souřadnic definovaného okolí hlášky - Protože hlášky z důvodu přesnosti
GNSS neodpovídají vždy přesně poloze dané silniční komunikace, je definováno
okolí (konkrétně obdélník), kde se může hláška vyskytovat, viz dále.
4. Výběr všech složených křivek z mapy - Na základě hlášek je třeba identifikovat
platné složené křivky z OSM, tj. ty složené křivky, v jejichž okolí se hláška skutečně
vyskytuje. Nejprve jsou načteny čtyři hraniční body ve složené křivce, tvořící
obdélník: [𝑊𝐴𝑌 𝑙𝑎𝑡𝑚𝑎𝑥 ,𝑊𝐴𝑌 𝑙𝑎𝑡𝑚𝑖𝑛 ,𝑊𝐴𝑌 𝑙𝑜𝑛𝑚𝑎𝑥 ,𝑊𝐴𝑌 𝑙𝑜𝑛𝑚𝑖𝑛 ].Následně jsou
spočítány hraniční hodnoty obdržené hlášky: [ 𝑃𝑂𝑆 𝑙𝑎𝑡𝑚𝑎𝑥 , 𝑃𝑂𝑆 𝑙𝑎𝑡𝑚𝑖𝑛 ,
𝑃𝑂𝑆 𝑙𝑜𝑛𝑚𝑎𝑥 ,𝑃𝑂𝑆 𝑙𝑜𝑛𝑚𝑖𝑛 ] Následně je provedena kontrola splnění nutné soustavy
podmínek:
𝑃𝑂𝑆 𝑙𝑎𝑡𝑚𝑖𝑛 < 𝑊𝐴𝑌[𝑙𝑎𝑡𝑚𝑎𝑥 ]
𝑃𝑂𝑆 𝑙𝑎𝑡𝑚𝑖𝑛 > 𝑊𝐴𝑌[𝑙𝑎𝑡𝑚𝑖𝑛 ]
𝑃𝑂𝑆 𝑙𝑜𝑛𝑚𝑖𝑛 < 𝑊𝐴𝑌 𝑙𝑜𝑛𝑚𝑎𝑥
𝑃𝑂𝑆 𝑙𝑜𝑛𝑚𝑖𝑛 > 𝑊𝐴𝑌[𝑙𝑜𝑛𝑚𝑎𝑥 ]
Pokud je výše napsaná soustava podmínek splněna, dochází k průniku okolí hlášky s
definovaným okolí složené křivky, a proto je možné složenou křivku považovat za
platnou.
5. Kontrola azimutu pro každý úsek každé platné složené křivky - Dále je třeba určit
směr jízdy vozidla, ze kterého hlášky přicházejí. Ten je určen na základě porovnání
azimutu vozidla (+- 5 °), který je součástí hlášky, s azimutem úseku uloženým v
databázi.
13
6. Výpočet vzdálenosti bodu od úseku s odpovídajícím azimutem – Pomocí výpočtu
popsaného blíže v podkapitole Metodiky mapování v projektu jsou nalezeny
vzdálenosti hlášky od platných složených křivek.
7. Kontrola vybraných dat –Vybrané složené křivky a jejich odpovídající úseky nejsou
nezaznamenávány v případě že se jedná např. o tunely, parkoviště apod.
8. Uložení údajů o směru, času v UTC formátu, ID zařízení a čísla úseku – Hláška je
přiřazena nejbližšímu úseku, tj. s nejmenší vzdáleností hlášky od úseku, který je
platný.
 Proces generování mapy
Pro větší přehlednost a uživatelskou přívětivost vytvořené aplikace jsou podle stupně
podrobnosti zobrazovány pouze vybrané komunikace1. V tabulce níže je k nalezení přehledný
seznam použitých tagů pro jednotlivé úrovně zobrazování. Úroveň 1 obsahuje např. zobrazení
dálnic a silnic 1. třídy, v úrovni 2 se vyskytují silnice 2. třídy a v poslední, tj. nejpodrobnější
úrovni 3 jsou k nalezení silnice 3. třídy i místní komunikace. V tabulce níže naleznete
všechny tagy, na základě kterých probíhá kategorizace příslušné komunikací pro příslušnou
úroveň a tagy, které se používají v bodě 7 procesu zaznamenávání dat.
Úroveň 1
Úroveň 2
Úroveň 3
Without
GNSS
OSM tagy
trunk, motorway, primary, trunk_link, motorway_link, primary_link
secondary, secondary_link
tertiary, residential, tertiary_link, residential_link
service, living_street, param: tunnel
Kompletní proces generování mapy se skládá z několika dílčích po sobě jdoucích kroků:
1. Výpočet průměrných rychlostí pro všechny složené křivky– viz kapitola 4.
2. Definování parametru Layer - Pokud je definován parametr layer, bude
vygenerována mapa pouze pro odpovídající vrstvu (úroveň), pokud daný parametr
definován není, bude načtena celá mapa.
3. Definování parametru Shift - Pomocí parametru Shift docílíme posunutí každé linie
úseku vpravo ve směru jízdy za účelem logického rozlišování směru na mapě. Je-li
cílem posunout dva body𝐴[𝑙𝑎𝑡, 𝑙𝑜𝑛], 𝐵[𝑙𝑎𝑡, 𝑙𝑜𝑛] vpravo, je třeba spočítat úhel mezi𝐴
a 𝐵 , dále provést konverzi kartézské vzdálenosti posunu do systému WGS84, tj.
přepočítat metry na stupně pro zeměpisnou délku a šířku, které jsou následně uloženy
do proměnné 𝑆𝐻𝐼𝐹𝑇[𝑙𝑎𝑡, 𝑙𝑜𝑛]. Na základě vypočteného úhlu lze posunout oba body𝐴
i 𝐵 podle následujících vztahu:
𝐴𝑙𝑜𝑛 = 𝐴𝑙𝑜𝑛 + cos 𝑎𝑧 ⋅ 𝑆𝐻𝐼𝐹𝑇𝑙𝑜𝑛
𝐴𝑙𝑎𝑡 = 𝐴𝑙𝑎𝑡 − sin 𝑎𝑧 ⋅ 𝑆𝐻𝐼𝐹𝑇𝑙𝑎𝑡
1
Neobsazené složené křivky nejsou vykreslovány
14
Ve výchozím nastavení jsou všechny zobrazované body posunuty o 3 metry vpravo ve
směru jízdy na základě výše uvedeného postupu.
 Proces vykreslování dat
Kompletní proces generování mapy se skládá z několika dílčích po sobě jdoucích kroků:
1. Načtení HTML struktury webové stránky
2. Pomoci technologie AJAX jsou prováděny následující kroky:
2.1. Načtení první vrstvy (úrovně) zobrazované mapy - Je zaslán dotaz pro generování
GeoJson2 s vlastnostmi shift =1, layer=1
2.2. Načtení druhé, resp. třetí vrstvy zobrazované mapy na základě přiblížení
uživatelem
2.3. Aktualizace mapy -Každých 60 sekund dochází k načítání aktuálního stavu dopravy
na silniční síti.
 Použitý software
PostgreSQL [11]

relační databázový systém, ve kterém byly vytvořeny všechny tabulky a relace pro
práci s FCD daty
Ruby [12]

primárně využívaný programovací jazyk, ve kterém byl vyvíjen algoritmus pro
stanovení jízdních dob na základě dostupných FCD dat
 Kalibrace modelu na základě vzniklých podnětů
V průběhu řešení projektu bylo nutné výsledný model několikrát kalibrovat na základě
vzniklých podnětů, z nichž jsou některé uvedeny níže:


2
Uživatelsky nevýhodná definice složených křivek, které často nereflektovaly
přítomnost křižovatky, čímž docházelo k nepřívětivému grafickému znázornění
výsledků, byla vyřešena vytvořením tzv. mezikřižovatkových složených křivek.
Stále je nutné počítat s omezenou přesností GNSS přijímače, která způsobuje
především v oblastech místních komunikací zkreslené výsledky, kdy výsledná rychlost
stanovená modelem může být značně nízká. Výsledné rychlosti jsou tedy nejvíce
reprezentativní pro komunikace 1. a 2. třídy, v případě komunikací 3. třídy jsou
výsledky méně přesné.
GeoJson je nadstavbou nad JSONem (Java Script Object Notation), což je odlehčený formát pro výměnu dat.
15
 Dopravní aplikace
Při návrhu dopravní aplikace je kladen důraz na její uživatelskou přívětivost a funkčnost.
Funkčností je rozuměno spolehlivé plnění tří systémových procesů, a to získávání dat z
plovoucích vozidel, zobrazování dat na proměnné informační tabule a zobrazování dat
uživateli v podobě interaktivních webových stránek.
Rámcová architektura dopravní aplikace
Na obrázku číslo 4 lze vidět funkční architekturu navržené dopravní aplikace. Navržená
architektura obsahuje čtyři základní prvky:
1. Server s aplikací umístěný na Ústavu dopravní telematiky Fakulty dopravní, ČVUT,
běžící nepřetržitě. Systém je centralizovaný tj. všechna komunikace a výpočty
probíhají pouze pomocí jednoho centrálního serveru s běžící aplikací.
2. Plovoucí vozidla, ze kterých jsou získávány hlášky.
3. Proměnné informační tabule sloužící pro zobrazování dojezdových časů účastníkům
silničního provozu.
4. Uživatel, jemuž je umožněno nahlédnout do mapového rozhraní s aktuálním stavem
dopravy a následně mu je naplánována nejvhodnější trasa s uvažováním vypočtených
jízdních dob. Konkrétně se jedná o zobrazování na OSM s použitím frameworku
OpenLayers.
Obrázek 4 Rámcové schéma dopravní aplikace [9]
Podrobné schéma dopravní aplikace
Podrobné schéma dopravní aplikace lze vidět na Obrázku 5. Centrální řídící server umístěný
na Ústavu dopravní telematiky se skládá ze tří dílčích serverů, z nichž každý slouží k předem
definovaným účelům. Konkrétně se jedná o servery:
16





Sinatra [13]- REST server, který slouží primárně k přijímání a zpracovávání hlášek
PostgreSQL [11]- interní databáze projektu
Ruby on Rails [14]- server pro webovou aplikaci, tzn. server komunikující
s uživatelem
OpenLayers [15]- framework pro zobrazování mapových dat na webových stránkách
Material Design Lite [16]-volně stažitelná sada nástrojů pro tvorbu webu a webových
aplikací.
Samotný proces zpracování hlášky pak lze podrobněji definovat v procesech:
1. Načtení mapy z interní databáze Postgres do serveru SINATRA
2. Server SINATRA přijímá hlášku z vozidla vybaveného GNSS přijímačem
3. Server SINATRA zasílá GNSS přijímači zpět informaci o tom, zda hláška byla přijata
správně, zároveň dochází k výpočtu a aktualizaci mapy a ta je uložena do databáze
4. Uživatel vstupuje pomocí webové aplikace do systému, web je součástí samostatného
serveru RAILS
5. Server RAILS zpracuje požadavek uživatele a zašle dotaz na databázi
6. Mapa je z databáze načtena na server RAILS
7. Dochází k zobrazení informace uživateli. K uživateli putují dva základní výstupy ze
serveru RAILS, a to webové stránky a mapa (výstup aplikace GeoJSON)
Obrázek 5 Podrobné schéma dopravní aplikace [vytvořeno v 10]
17
5. Prezentace výsledků
 Konference
Projekt byl prezentován v roce 2015 na dvou vybraných konferencích prostřednictvím
příspěvků, a to konkrétně:


Young Transportation Engineers Conference 2015 v Praze
Conference of Doctoral students PEFnet 2015 v Brně
V rámci těchto konferencí vznikly dva výstupy v podobě prezentačních příspěvků (článků):
[1] Blümelová J. - Růžička J. - Boyarkin I. - Derbek P.: Stanovení dob jízdy pro proměnné
informační tabule na základě FCD dat. In YTEC 2015 - Sborník příspěvků konference. Praha:
České vysoké učení v Praze, Fakulta dopravní, 2015, čl. č. 30, s. 195-201. ISBN 978-80-0105791-9
[2] Blümelová J. - Růžička J. - Boyarkin I. - Derbek P.: Travel Time Estimation for Variable
Message Signs Based on Floating Car Data. In PEFnet 2015 Abstracts. Brno. Mendelova
univerzita v Brně, 2015, p. 15. ISBN 978-80-7509-362-2
 Webová aplikace
Webová aplikace je součástí úvodní stránky webových stránek projektu, které jsou k nalezení
na doméně: traff-info.k620.fd.cvut.cz
Po načtení stránek uživatel pozoruje mapu s barevně znázorněnými složenými křivkami, které
názorně demonstrují aktuální stav dopravy v posuzované oblasti:



zelená barva- Plynulý dopravní proud. Vypočtená průměrná rychlost na složené
křivce se limitně blíží definované maximální povolené rychlosti dané složené křivky
oranžová barva- Ovlivněný dopravní proud. Vypočtená průměrná rychlost na složené
křivce je mírně nižší než definovaná maximální povolená rychlost dané složené křivky
červená barva- Dopravní kongesce. Vypočtená průměrná rychlost na složené křivce
je výrazně nižší než definovaná maximální povolená rychlost dané složené křivky.
Po kliknutí uživatele na vybranou složenou křivku se zobrazí malá tabulka se základními
informacemi o dané složené křivce, příklad tabulky a legenda k tabulce je k nalezení níže:
name: Čuprova
sum_speed: 91
amount: 2
direction: f
max_speed: 50
avg_speed: 48
18






name - Název ulice.
sum_speed- Součet rychlostí všech vozidel, která projela danou složenou křivkou v
pozorovaném intervalu.
amount- Počet bodů, kterými je definovaná daná složená křivka.
direction - Údaj o směru.
max_speed - Definovaná maximální povolená rychlost dané složené křivky.
avg_speed - Vypočtená průměrná rychlost dopravního proudu na dané složené křivce.
 Původní mobilní aplikace pro Android
Nad rámec původně zamyšlených výstupů k prezentaci vznikla také vlastní mobilní aplikace
pro operační systém Android. Uživatel mobilního zařízení se tímto může snadno zapojit do
procesu sběru FCD dat. Původní mobilní aplikace je k nalezení ke stažení na webových
stránkách projektu.
 Výstup pro PIT
Proměnná informační tabule je zařízení určené k poskytování dopravních informací při
mimořádných situacích, jako jsou kongesce, uzávěry důležitých tras, nebo informování
účastníků silničního provozu o aktuální jízdní době do cíle na vybraných komunikacích.Na
základě získané informace o jízdní době se řidič může včas rozhodnout a zvolit optimální
trasu cesty. Informace mohou být v textové nebo v grafické podobě zobrazovány i
dynamicky.
V praxi jsou proměnné informační tabule většinou schopny přijímat jako vstup soubory ve
formátu XML. Na základě našich dat jsme schopni vygenerovat jakýkoliv výstup, tedy i
soubor XML. Ověření funkčnosti našeho řešení na reálné proměnné informační tabuli je tak
podmíněno pouze její dostupností.
19
6. Použitá literatura a odkazy na použitý software
[1] Dynamic Travel Time Provision for Road Networks [online]. [accessed. 15. July 2015]. Retrieved z:
http://publik.tuwien.ac.at/files/PubDat_168982.pdf
[2] Yong-chuan, Z., Xiao-qing, Z., li-ting, Z. and Zhen-ting, C. (5541) ‘Traffic Congestion Detection Based On
GPS Floating-Car Data’, ProcediaEngineering, 15, pp. 5541–5546. doi: 10.1016/j.proeng.2011.08.1028.
[3] Movable Type Scripts: Calculate distance, bearing and more between Latitude/Longitude points, [online]. ©
2002-2015 Chris Veness, [cit. 7.1. 2016], Dostupné z: http://www.movable-type.co.uk/scripts/latlong.html
[4] Chien, S. I.-J. and Kuchipudi, C. M. (no date) Dynamic Travel Time Prediction with Real-Time and Historic
Data. Availableat: http://ascelibrary.org/doi/10.1061/(ASCE)0733-947X(2003)129%3A6(608) (Accessed: 15
July 2015).
[5] MAXWELL, Jones, Yanfeng GENG, Nikovski DANIEL and Hirata TAKAOMI. Predicting Link Travel
Times from Floating Car Data. IEEE Xplore [online]. 6. October 2009 [accessed. 15. July 2015]. Retrieved z:
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6728483
[6] SEVLIAN, R. (no date) Travel Time Estimation Using Floating Car Data. Available at:
http://cs229.stanford.edu/proj2010/Sevlian-TravelTimeEstimationUsingFloatingCarData.pdf (Accessed: 15 July
2015).
[7] BEIPENG, Mu, Hu JIANMING, Zhao TINGTING and Zhang YI. Evaluating the Performance of Link
Travel Time Estimation Based on Floating Car Data. IEEE Xplore [online]. 11. November 2012 [accessed. 15.
July 2015]. Retrieved z: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5663161&tag=1
[8] RUBY S., THOMAS D., HANSON D.: Agile Web Development with Rails 4 4th, ISBN 978-1-937785-56-7,
[online].
Pragmatic
Programmers
Llc
2013,
[cit.
7.1.
2015],
Dostupné
z:
http://www.directtextbook.com/isbn/9781937785567
[9] Icons made by OCHA, Freepik from www.flaticon.com, licensed by CC BY 3.00
[10] Icons made by Gliffy diagrams, Verze: 1.0.29, [online]. [cit. 17.1. 2016]. Dostupné z:
https://chrome.google.com/webstore/detail/gliffy-diagrams/bhmicilclplefnflapjmnngmkkkkpfad
[11] PosgreSQL [online]. © 1996-2016 The PostgreSQL Global Development Group, [cit. 7.1. 2016], Dostupné
z: http://www.postgresql.org
[12] Ruby: A Programer's best friend, [online]. © 2006 - Proudly maintained by members of the Ruby
community, [cit. 7. 1. 2016 ], Dostupné z: https://www.ruby-lang.org
[13] Blake Mizerany: Sinatra, [online]. [cit. 7.1. 2016]. Dostupné z: http://www.sinatrarb.com/
[14] Imagine what you could build if you learned Ruby on Rails, [online]. [cit. 7.1. 2016]. Dostupné z:
http://rubyonrails.org/
[15] OpenLayers 3, [online]. Code licensed under the 2-Clause BSD. All documentation CC BY 3.0 [cit. 7.1.
2016]. Dostupné z: http://openlayers.org/
[16] Material Design Lite, [online]. [cit. 7.1. 2016]. Dostupné z: http://www.getmdl.io/
[17] Distance between Latitude and Longitude Coordinates in SQL, [online]. Dayne Batten 09/2015. [cit 8. 1.
2015.] Dostupné z: http://daynebatten.com/2015/09/latitude-longitude-distance-sql/
20