Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta

Aplikace algoritmu hledání nejkratší cesty v geografických datech silniční sítě České republiky

Bakalářská práce

Vedoucí práce: RNDr. Tomáš Hála, Ph. D. Jan Grmela

2009

Děkuji RNDr. Tomáši Hálovi, Ph.D. za věcné připomínky týkající se zpracování bakalářské práce a za odborné rady související s vytvo­ řením softwarového balíku, jímž se tato práce zabývá.

Prohlašuji, že jsem tuto bakalářskou práci zpracoval samostatně s pou­ žitím literatury, která je uvedena v seznamu. V Brně 20. května 2009 ……......

7

Abstract

This work discusses a graph shortest­path finding algorithm applica­ tion in context with a Czech motorway network data. The introduction ad­ umbrates the input geodata, provided by the Road and Motorway Director­ ate of the Czech Republic, characteristics. The further text analyses the possibilities in presentation and storage of the data in a common database systems along with a input data transformation procedure. The work con­ tinues with a short introduction to the graph theory and pathfinding men­ tioning the common pathfinding algorithms. In fine the server and the cli­ ent side of the shortest path­finding program package buildup, installation and setup is described.

Keywords

pathfinding, routing, graphs, PostgreSQL, PostGIS, pgRouting, Perl

Abstrakt

Tato bakalářská práce pojednává o aplikaci grafového algoritmu pro hledání nejkratších cest v geografických datech silniční sítě České repub­ liky. V úvodní části je nastíněna problematika vstupních geodat a jsou po­ psána data poskytovaná Ředitelstvím silnic a dálnic České republiky. Dále jsou rozebrány možnosti zobrazení a uložení těchto dat v obvyklých data­ bázových systémech a popsán způsob převodu zdrojových dat do cílového systému. Následně se práce zabývá problematikou teorie grafů a hledání cest v grafech. Jsou zmíněny obvyklé algoritmy hledání. Závěrem práce po­ pisuje sestavení serverové a klientské části programového balíku pro hle­ dání nejkratších cest, jejich instalaci a nastavení.

Klíčová slova

hledání nejkratší cesty, grafy, PostgreSQL, PostGIS, pgRouting, Perl

9

Obsah

1 Úvod a cíl práce...... 11 1.1 Úvod do problematiky...... 11 1.2 Cíl práce...... 12 2 Struktura geodat silniční sítě ČR...... 13 2.1 Formát vstupních dat Silniční databanky Ostrava...... 14 2.2 Formát vstupních dat Českého statistického úřadu...... 15 3 Programové vybavení pro serverovou část...... 17 3.1 Výběr databázového serveru...... 17 3.2 Popis databázového serveru PostgreSQL a rozšíření PostGIS...... 18 3.3 Rozšíření pgRouting...... 19 3.4 Základní principy výpočtu nejkratší cesty v softwaru pgRouting...... 20 3.5 Volba programovacího jazyka projektu...... 22 4 Sestavení převodníku geografických dat...... 24 4.1 Návrh cílové databáze...... 24 4.1.1 Tabulka cities (obce)...... 24 4.1.2 Tabulka districts (okresy)...... 25 4.1.3 Tabulka edges (úseky)...... 25 4.1.4 Tabulka node_types (druhy uzlů)...... 26 4.1.5 Tabulka nodes (uzly)...... 26 4.1.6 Tabulka regions (kraje)...... 27 4.1.7 Tabulka roads (silnice)...... 27 4.1.8 Tabulka systems (silniční tahy)...... 27 4.1.9 Systémové tabulky PostGISu...... 27 4.2 Převodník dat Ředitelství silnic a dálnic ČR...... 28 4.2.1 Získání dat...... 28 4.2.2 Zpracování dat...... 28 4.3 Převodník dat Českého statistického úřadu...... 31 4.3.1 Získání dat...... 31 4.3.2 Zpracování dat...... 31 5 Serverová část aplikace pro hledání nejkratší cesty...... 32 5.1 Návrh komunikačního protokolu...... 33 5.1.1 Popis formátu GPX...... 34 5.1.2 Rozšíření specifikace GPX...... 34 5.2 Prerekvizity a instalace rozšíření pgRouting...... 36 5.3 Instalace serverové části aplikace...... 38 10

5.4 Implementace serverové části aplikace...... 39 5.4.1 Volba algoritmu pro hledání nejkratší cesty...... 39 5.4.2 SQL rozhraní rozšíření pgRouting...... 41 5.4.3 Hlavní modul...... 43 5.4.4 Modul generátoru GPX a výjimek...... 44 6 Klientská část aplikace pro hledání nejkratší cesty...... 45 6.1 Instalace klientské části aplikace...... 45 6.2 Implementace klientské části aplikace...... 45 7 Návod k použití aplikace...... 46 7.1 Import dat do databáze PostgreSQL...... 46 7.2 Nastavení serveru...... 47 7.3 Použití klienta...... 48 7.3.1 Spouštěcí volby klienta...... 48 7.3.2 Příklady příkazů klienta...... 49 8 Diskuse...... 50 8.1 Posouzení výsledků...... 50 8.2 Porovnání s komerčními systémy...... 51 9 Závěr...... 53 Seznam použité literatury...... 55 Přílohy...... 57 Trasa z Hradce Králové do Čeperky...... 57 Cesta z Odrovic do Kupařovic...... 58 Schéma databáze...... 60 Příklad použití klienta...... 61 Zobrazení cesty z Brna do Prahy vypočtené vytvořenou aplikací...... 63 Zobrazení cesty z Brna do Prahy vypočtené Google Maps...... 64 1 ÚVOD A CÍL PRÁCE 11

1 Úvod a cíl práce

1.1 Úvod do problematiky

Každý si občas v životě klademe jednoduchou otázku – jak se dostanu nejrychleji z místa A do místa B? Pro lidský mozek s dostatkem nezbytných znalostí je tato otázka obvykle poměrně snadno řešitelná s uspokojivým vý­ sledkem. Není tomu tak ale v případě stroje – počítače. Počítač, přesněji, matematický algoritmus, který dokáže takovou nejkratší cestu zjistit se ne­ může „prostě zamyslet“ a vybrat do několika málo sekund nejkratší variantu bez zvážení všech ostatních, podobně jak to dělá lidský mozek. Ten pracuje se zkušenostmi a dokáže během krátkého okamžiku postihnout obrovské množství vlivů na délku cesty. A to jak momentálních (například dopravní zácpa), tak dlouhodobých (například uzavřená silnice). Mozek taktéž umožňuje mnohé informace ignorovat, pokud nejsou pro daný problém podstatné. I přes tyto možnosti se však nedokáže vypořádat s detailním plánováním na velké vzdálenosti – nedokáže udržet v paměti současně celou představu o možných trasách a taktéž nedokáže provádět efektivní plánování při nedostatku informací (např. jen na základě pohledu do mapy v neznámém prostředí). Výsledek, který mozek vyprodukuje i na krátké vzdálenosti nemusí být nutně ten nejlepší. Obvykle se ale jeho časová náročnost přibližuje opti­ mální variantě, v závislosti na množství informací, které máme k dispozici a našich celkových znalostech a schopnostech. Pokud však stejnou úlohu zadáme počítači, brzy zjistíme, že na první pohled triviální úloha je jak ča­ sově, tak prostorově extrémně složitá. Dokonce tak složitá, že příbuzná úlo­ ha, tzv. problém obchodního cestujícího1 byla zařazena jako podmnožina problému P = NP mezi matematické problémy tisíciletí, za jejich vyřešení dostane podle řešitel po milionu dolarů. (Develin, 2005) Pro zjištění vý­ sledku je totiž nutné projít všechny možné varianty, z čehož plyne, že s růs­ tem počtu uzlů na grafu (v našem případě křižovatek na silnicích) roste složitost řešení exponenciálně. [4]

1 Obchodní cestující má za úkol navštívit všechna města ve svém itineráři tak, aby cestováním mezi nimi strávil co nejméně času – pohyboval se po nejkratší cestě mezi nimi (Problém obchodního cestujícího, 2009).[23] 1 ÚVOD A CÍL PRÁCE 12

V dnešní době, kdy již existují dostatečně výkonné počítače, je možné pro rozumně velkou silniční síť nechat počítač takovouto úlohu vyřešit i „hrubou silou“ – vyzkoušením všech možných variant. I tak by však tento způsob řešení zabral dlouhý čas a tak je tento typ úloh v obvykle řešen algo­ ritmy mnohem rychlejšími. Tyto využívají ke své práci genetické a heuris­ tické principy. Tím vlastně umožníme počítači vykonávat to, co dělá lidský mozek – orientovat se odhadem a nebýt nucen dbát na dokonalou přesnost a stoprocentně nejlepší výsledek. Obvykle nám totiž stačí jen výsledek, který se k nejlepšímu přibližuje.

1.2 Cíl práce

Cílem práce je navrhnutí a vytvoření klientského a serverového programového balíku pro vyhledávání nejkratší cesty v silniční síti České republiky. Dílčími cíli je porovnání dostupných databázových prostředků pro uložení geografických dat2, vytvoření a doplnění software pro převod dat pu­ blikovaných Ředitelstvím silnic a dálnic České republiky a Českého sta­ tistického úřadu a porovnání a aplikace algoritmů pro hledání nejkratší cesty v grafech. Aplikace, která vznikne, má uživateli umožnit snadné vyhledávání nejkratší cesty v závislosti na zadaných parametrech.

2 Geografická data, zkráceně geodata jsou zeměpisné informace počítačově zpracované nebo uložené s určenou zeměpisnou polohou, rozměry a obvykle také bližním popisem jako je druh či název. 2 STRUKTURA GEODAT SILNIČNÍ SÍTĚ ČR 13

2 Struktura geodat silniční sítě ČR

Bezpochyby nejdůležitější částí celé práce jsou zdrojová data. Jak je po­ psáno v práci Převodník geografických dat z roku 2008, získání takových dat je velmi obtížné, zejména pokud máme v úmyslu použít data volně dostupná a nikoli komerční. [9] Od doby napsání zmíněné práce se situace příliš nezměnila. Jediným zlepšením je dosažení importu silnic první a druhé třídy do české části projektu OpenStreetMap.org3. I tak je stále nejvhodnějším zdrojem dat pro tuto práci Silniční databanka Ostrava ŘSD ČR vzhledem k nízké garanci přesnosti dat projektu OpenStreetMap.org. [16] Jak jsou však data, která potřebujeme získat, uložena? V úvodu byly zmíněny uzly v grafu. Skutečně, tato zmínka velmi úzce souvisí s datovou strukturou, se kterou budeme převážnou část práce pracovat. Totiž s grafem. Graf je zřejmě nejvhodnější strukturou pro uložení silniční sítě. Tato vhodnost je zřejmá – snadno si představíme uzly grafu jako křižovatky a hrany jako silnice mezi nimi.

Ilustrace 1: Zobrazení mapy jako grafu

Výše uvedená ilustrace zobrazuje část mapy jižní Moravy (podklad Mapy.cz), na kterém je pomocí červených čar (hrany) a modrých bodů (uzly) zobrazen graf oblasti. 3 OpenStreetMap.org je projekt, který má za cíl vytvořit kompletní mapu světa až na úroveň podobnosti ulice (proto „streetmap“) jen za použití volných geodat. 2 STRUKTURA GEODAT SILNIČNÍ SÍTĚ ČR 14

Z ilustrace je zřejmé, že převod takovéto mapy na graf není příliš komplikovaný. Stačí jen znát přesné souřadnice uzlů (křižovatek) a to, ja­ kým způsobem jsou mezi sebou propojeny, což je obvykle zobrazeno mate­ maticky prostřednictvím incidenční matice (konkrétně v této úloze matice vzdáleností vrcholů). Tato matice má n řádků a n sloupců, kde n je počet uzlů grafu. Mezi těmito uzly je jednoduchý vztah – pokud spolu uzly sousedí (tedy mezi nimi existuje spojnice), je v matici délka spojnice. Pokud nikoli, je vyplněna nekonečná hodnota. Je­li matice úhlopříčně symetrická, nejde o orientovaný graf. Neorientovaný graf se ale obvykle v silniční síti nevysky­ tuje, jelikož tato vlastnost by znamenala, že v celé síti neexistuje jediná jednosměrná cesta.

2.1 Formát vstupních dat Silniční databanky Ostrava

V případě, že chceme pracovat s daty, které nám Silniční databanka Os­ trava poskytuje, musíme nejdříve zjistit, jakým způsobem jsou tato data uložena a jak s nimi můžeme pracovat. Při popisu vstupních dat je možné vycházet z již zmíněné práce Převodník geografických dat, ve která jsou data charakterizována. Vstupní data jsou uložena ve formátu ESRI Shapefile. Formát je dobře známý a existuje k němu kompletní dokumentace z roku 1998 od společnosti Environmental Systems Research Institute. Formáty společnosti ESRI jsou nepsaným standardem v GIS aplikacích a tudíž je v téměř každé aplikaci pracující s geodaty podpora těchto formátů na vysoké úrovni. Po bližším seznámení navíc lze zjistit, že popisná tabulka Shapefile je v data­ bázovém formátu DBase III, který lze číst i v aplikacích nesouvisejících s ge­ ografickým informačními systémy. Předpoklad čitelnosti a exportovatelnosti je tedy splněn.[6] Totéž se bohužel nedá říci o tom, jakým způsobem jsou datové položky uspořádány uvnitř těchto struktur (konkrétně v popisných tabulkách). Uveďme si příklad: každá silnice (úsek) má přiřazeno jedinečné ID. Toto ID není numerické, jak bychom obvykle v databázi očekávali, nýbrž se skládá z dvou identifikátorů křižovatek (uzlů), mezi nimiž tato silnice vede. Naneštěstí, ani identifikátory křižovatek nejsou čistě numerické. Jejich for­ mát je možné popsat regulárním výrazem [0-9]{4}[ABC]{1}[0-9]{3}[0- 2 STRUKTURA GEODAT SILNIČNÍ SÍTĚ ČR 15

9\ ]{2}. Je zřejmé, že pouhé uložení databázových tabulek v jiném formátu nepostačí – je třeba databázi navrhnout znovu, v souladu s pravidly pro tvorbu databází, normalizaci (Lacko, 2001). Databáze, která tímto postupem vznikne, bude klást menší prostorové a výkonové nároky na databázový stroj při zachování všech v ní dosud uložených údajů.[12] Vstupní data získaná z webu Ředitelství silnic a dálnic ČR mají však je­ den zásadní nedostatek. Ten se ovšem projeví až ve chvíli, kdy budeme uva­ žovat na tím, jakým způsobem můžeme zjistit například cestu z Prahy do Brna. Vstupní data totiž nebyla georeferencována (geokódována). Místům zobrazeným na mapě nebyl podle zeměpisných souřadnic přiřazen místní název. Tabulky sice disponují v některých případech alespoň rámcovým označením místa, toto však v mnoha případech chybí nebo není dostatečně konkrétní. Tento zásadní nedostatek se jevil na první pohled jednoduše řešitelný. Původně bylo zamýšleno získat data z projektu GeoNames.org, který nabízí všechna česká sídla a polohy mnoha dalších prvků (řeky, louky, lesy, …). Po analýze a zkušebním importu do databáze, bylo však zjištěno, že mají je­ den zásadní nedostatek. Sídla jsou sice správně zaměřena, taktéž je připoje­ na informace o kraji, chybí však údaj o okresu a obvykle i počtu obyvatel. Tento nedostatek způsobuje nemožnost rozlišit mezi dvěma sídly ve stejném okresu se stejným názvem, což by v některých případech mohlo být limitují­ cí. Tento zdroj tedy není možné použít. Logickým zdrojem dat pro Českou republiku jsou údaje Českého statistického úřadu. Nemůžeme sice již zo­ becnit převodní postupy tak, aby je bylo možné použít například na Slo­ vensku, získáme však data excelentně zaměřená s vysokou spolehlivostí.

2.2 Formát vstupních dat Českého statistického úřadu

Český statistický úřad nabízí na svých webových stránkách pro účely práce se ulicemi, sídly i vyššími správními celky specializovanou aplikaci – Prohlížeč UÍR­ZSJ. Podle ČSÚ je tento prohlížeč „soustava databázových čí­ selníků jednotek územně správního, technického a sídelního členění státu do úrovně podrobnosti částí obcí, katastrálních území a základních sí­ delních jednotek“. Obsahuje tedy velké množství statistických dat různého 2 STRUKTURA GEODAT SILNIČNÍ SÍTĚ ČR 16 zaměření. Co je však nejdůležitější, jeho součástí je i databáze sídel spolu s jejich statistickými údaji a zaměřením v souřadnicovém systému S­JTSK (Voříšek, 2008). Tato databáze obsahuje i propojení mezi tabulkami sídel, krajů a okresů – každou obec je tak možné přesně lokalizovat.[3][19] Data jsou, jak je v české státní správě běžné, ve formátu DBase III. Pů­ vodním účelem těchto dat je využití přímo v přiložené aplikaci, z dostupnosti dokumentační tabulky POLOZKY.DBF lze však usoudit, že ČSÚ počítá s využi­ tím dat i v externích programech. Tato skutečnost značně usnadňuje převe­ dení dat do jiných formátů. Následující seznam popisuje tabulky a využité sloupce pro získání tabulky obcí, krajů a okresů.

– OKRESY.DBF;

– KN – pořadové číslo kraje;

– KNOK – pořadové číslo okresu;

– NAZKR – název kraje;

– NAZOK – název okresu.

– OBCE.DBF.

– KN – pořadové číslo kraje;

– KNOK – pořadové číslo okresu;

– NAZOB – název obce;

– OB01 – počet obyvatel v roce 2001;

– SXOB – x­ová souřadnice v S­JTSK;

– SYOB – y­ová souřadnice v S­JTSK.

Jelikož je u každé obce uvedeno, v jakém kraji a okresu se nachází, je možno ji propojit s tabulkou okresů. Ta je následně rozdělena na dvě tabulky – okresy a kraje. Původní tabulka okresů totiž obsahuje nadbytečná duplicitní data. Podle práce Jaroslava Zámiše, která se daty UÍR­ZSJ zabývá podrobně, je nutné pro správné zobrazení přidat před obě polohové souřadnice minus, jinak by zobrazení bylo chybné (obce by byly zobrazeny jinam).[20] 3 PROGRAMOVÉ VYBAVENÍ PRO SERVEROVOU ČÁST 17

3 Programové vybavení pro serverovou část

Máme­li v úmyslu uskladnit geografická data takto rozsáhlého celku ja­ kým je celá silniční síť České republiky, je třeba se důkladně zamyslet nad tím, kde je uložíme a jaké programové vybavení pro tuto operaci využijeme. Již z povahy zadání je nutné, aby k údajům mohlo přistupovat více uživatelů zároveň, ideálně z více různých počítačů. Je tedy nasnadě zabývat se pouze komplexními databázovými systémy, které podobnou funkcionalitu nabízejí již v základním provedení a jsou na vzdálený přístup a práci navr­ žené od počátku.

3.1 Výběr databázového serveru

V současnosti poskytuje téměř každý výrobce databázového systému alespoň základní podporu pro uložení geografických objektů. Jde ze zná­ mých SŘBD například o IBM DB2, Microsoft Access, PostgreSQL, Microsoft SQL Server, MySQL a Oracle. Podpora pro geodata není ve všech systémech stejná, nejdokonalejší jsou v této oblasti specializované servery firmy ESRI (ArcGIS a ArcSDE) a databázové systémy Oracle a PostgreSQL s rozšířením PostGIS (Geodatabase, 2009).[22] Jak však vybrat nejvhodnější systém? Pokud bychom uvažovali pouze systémy s otevřeným zdrojovým kódem, za nejvhodnější kandidáty na úložiště geoinformací by bylo možno považovat PostgreSQL a MySQL. Po­ rovnáme­li rozsah GIS rozšíření, které oba systémy nabízejí (například prostřednictvím jejich technické dokumentace nebo knih od Bruce Momija­ na či Paula Duboise), vyjde nám jako jasný vítěz databázový systém PostgreSQL. V kombinaci s rozšířením PostGIS (krátce popsáno česky na­ příklad v příspěvku pánů Boříka a Honzíka na 25. konferenci o počítačové grafice) jde o nejdokonalejší zdarma dostupný databázový software pro uložení a práci s geografickými informacemi.[13][5][1] PostgreSQL je výhodnou volbou z mnoha dalších důvodů – je například dostupné na mnoho platformách (Windows, Linux, Mac OS, Solaris, …) a to jak v 32bitových, tak 64bitových sestaveních a vzhledem k otevřenému zdrojovému kódu je to systém snadno rozšiřitelný. Taktéž nejsme vázání na jednu určitou platformu, což nám umožňuje kupříkladu nasazení stejného 3 PROGRAMOVÉ VYBAVENÍ PRO SERVEROVOU ČÁST 18 programového vybavení jak na velkém podnikovém serveru, tak na kapesním počítači (v dnešní době ještě s mírně nadprůměrným hard­ warem).

3.2 Popis databázového serveru PostgreSQL a rozšíření PostGIS

PostgreSQL je volně dostupný databázový systém disponující mezi sys­ témy poskytovanými zdarma zřejmě největším množstvím funkcí a nejdoko­ nalejší podporou standardu SQL. Je snadno rozšiřitelný a to jak prostřednictvím modulů psaných v jazyce SQL, tak i například programů v C či jiném kompilovaném jazyce. Dlouhou dobu tomuto systému chyběla podpora ukládání a práce s geo­ daty. Vznikl tak projekt PostGIS, který si klade za cíl implementovat co možná největší funkcionalitu, která nějakým způsobem souvisí s ukládáním nebo zpracováním geografických dat dle standardu Simple Features z roku 2006 organizace Open Geospatial Consortium. PostGIS v současnosti pod­ poruje:[8]

– geometrické objekty – body, přímky, polygony, multibody, mul­ tipřímky, multipolygony a kolekce geometrických objektů;

– prostorové predikáty pro zjištění vztahů mezi objekty;

– prostorové operátory pro geoprostorová měření (např. plocha, vzdá­ lenost, délka, …);

– prostorové operátory pro geoprostorové množinové operace jako je sjednocení, průnik, symetrický průnik a doplněk;

– indexy pro urychlení prostorových dotazů;

– selektivní indexy pro podporu míchání prostorových a ostatních do­ tazů. PostGIS nám tedy umožňuje vykonávat obvyklé činnosti známé na­ příklad z grafických systémů společnosti ESRI jako je ArcMap v prostředí SQL. Tento přístup umožňuje automatizaci a hromadné zpracování velkého množství dat, stejně tak jako snadné sdílení nebo spolupráci. 3 PROGRAMOVÉ VYBAVENÍ PRO SERVEROVOU ČÁST 19

Jak PostgreSQL, tak samotný PostGIS je samozřejmě možné rozšiřovat uživatelskými funkcemi, které mohou například sloužit pro ukrytí složité aplikační logiky či jen pro prosté zpřehlednění kódu a usnadnění návrhu. Toho využívá i tato bakalářská práce – složitá funkcionalita je ukryta pod povrchem a uživatel (tedy spíše programátor) pracuje již přímo s vý­ stupními daty v přirozeném formátu.

3.3 Rozšíření pgRouting

V polovině roku 2006 byla na stránkách projektu PostLBS4 nabídnuta ke stažení první veřejná verze rozšíření PostGISu – pgRouting. Projekt Po­ stLBS si klade za cíl implementovat za pomocí PostGISu a PostgreSQL služ­ by vztahující se k poloze a služby georeferencování. Software pgRouting je částí tohoto projektu, který implementuje pomocí různých, uživatelsky voli­ telných algoritmů, routování, tzn. hledání cest v grafech (obvykle silniční sítě). Rozšíření pgRouting nám tedy umožňuje se v práci zaměřit čistě na zpracování dat do podoby, se kterou dokáže pracovat PostgreSQL a jejich prezentaci uživateli prostřednictvím vhodného rozhraní. Není třeba řešit složité technické problémy, se kterými bychom se setkali v případě, že bychom chtěli řešit hledání nejkratší cesty v grafu původní implementací v rámci této práce. Získáme tak nejen výhodu zrychleného vývoje, ale taktéž kód, který je dobře odladěný a vyzkoušený mnoha uživateli spolu s pravdě­ podobným výkonovým ziskem (= vyšší rychlost výpočtu). Projekt pgRouting urazil od svého vydání již dlouhou cestu, jak z hledis­ ka funkcionality, tak i z hlediska rychlosti a výkonu. Aktuální verze 1.30 na­ bízí dle dokumentace projektu následující možnosti:[15]

– výpočty nejkratší cesty;

– Dijkstrovým algoritmem;

– algoritmem A*;

– algoritmem Shooting Star.

– řešení problému obchodního cestujícího;

4 PostLBS je zkratka pro PosgreSQL location based services 3 PROGRAMOVÉ VYBAVENÍ PRO SERVEROVOU ČÁST 20

– výpočet cestovní vzdálenosti.

Jelikož se tato práce zabývá jen hledáním nejkratší cesty v silniční síti České republiky, budeme se dále zabývat jen prvním bodem – výpočtem nejkratší cesty.

3.4 Základní principy výpočtu nejkratší cesty v softwaru pgRouting

První možností, kterou nám pgRouting pro získání nejkratší cesty na­ bízí, je použití Dijkstrova algoritmu. Tento algoritmus je dobře známý a často v podobných úlohách využívaný (Hliněný, 2008, s. 30 a násl.).[10] Mezi jeho základní vlastnosti patří:

– konečnost (pro jakýkoliv konečný vstup algoritmus skončí);

– podpora pouze kladně ohodnoceného grafu;

– časová složitost O ([počet uzlů]2 + [počet hran]), použitím složitějších programových prostředků lze v případě grafů, které mají relativně malý počet vrcholů oproti počtu hran, dosáhnout složitosti O ([počet hran] + [počet vrcholů] + log [počet vrcholů]).

Pokud bychom princip algoritmu aplikovali na hledání nejkratší cesty v silniční síti, byl by postup následující: 1. Nastavíme všem křižovatkám v grafu hodnotu vzdálenosti od počátku – počáteční křižovatka má hodnotu nula, ostatní nekonečno. 2. Označíme všechny křižovatky jako nenavštívené a počáteční jako ak­ tuální. 3. U aktuální křižovatky zjistíme v případě všech nenavštívených sou­ sedních křižovatek vzdálenost (od počátku). Například tedy pokud má momentální křižovatka K1 vzdálenost 10 a je spojena s další kři­ žovatkou K2 cestou, která má délku 5, je vzdálenost ke K2 přes K1 5+10 tudiž 15. Pokud je vzdálenost menší než vzdálenost zjištěná dříve, přepíšeme ji novou hodnotou. 4. Jakmile jsme zjistili vzdálenosti ke všem sousedním křižovatkám, označíme aktuální křižovatku jako navštívenou; už ji znovu nebude­ me kontrolovat, její poznačená vzdálenost je konečná a minimální. 3 PROGRAMOVÉ VYBAVENÍ PRO SERVEROVOU ČÁST 21

5. Další křižovatku zvolíme tak, že vybereme nenavštívenou sousední s nejmenší vzdáleností od počátku. Pokračujeme krokem 3. Aplikací tohoto algoritmu získáme vzdálenosti všech křižovatek od počá­ teční křižovatky. Z výše uvedeného je zřejmé, že je vhodné tento algoritmus aplikovat jen na grafy o určitém rozsahu – jeho složitost roste kvadraticky s počtem vr­ cholů grafu. Navíc je pro získání výsledku nutné projít všechny vrcholy grafu. Tento problém se dá řešit tak, že nebudeme uvažovat výpočet pro celý graf ale vždy jen pro jeho určitou část, podgraf. Taktéž je možné dosáhnou značné optimalizace odhadem vzdálenosti mezi zdrojovým a cílovým uzlem grafu.

Těchto předpokladů využili ve své práci A Formal Basis for the Heuristic Determination of Minimum Cost Paths pánové Hart, Nilson a Raphael v roce 1972. Představili svůj algoritmus A, který byl později přeznačen na A* (A* search algorithm, 2009).[21] Algoritmus A* pracuje na podobných principech jako Dijstrův algorit­ mus, může však díky heuristickým vylepšením dosahovat mnohem lepšího výkonu. Časová složitost algoritmu se pohybuje od polynomiální v nejlepším případě, až po exponenciální v případě nejhorším (nepřesný odhad vzdá­ leností). A* je však velmi náročný na paměť, v nejhorším případě náročnost roste exponenciálně s počtem uzlů v grafu. V případě algoritmu A* budeme však na rozdíl od algoritmu Dijkstrova disponovat prostorovými daty pro jednotlivé uzly, tedy jejich polohou. Jinak by totiž heuristická aproximační funkce nemohla vypočítat, jak daleko se od sebe objekty nacházejí, čímž bychom přišli o hlavní devizu tohoto algo­ ritmu. Posledním algoritmem, který je nabízen programem pgRouting je algo­ ritmus Shooting Star. Jde o modifikovanou verzi5 algoritmu C* Dr. Flin­ senbergové z nizozemské univerzity v Eindhovenu. Tento algoritmus byl navržen ve vývojovém středisku Siemens VDO a zveřejněn v roce 2004 v roz­

5 Dle vyjádření Antona Patrusheva, který algoritmus v roce 2007 navrhl, neexistuje momentálně žádná práce, která by tento algoritmus a rozdíly oproti C* popisovala; veškeré informace v této bakalářské práci tedy pocházejí buď z práce Dr. Flinsbergové anebo z dokumentace pgRoutingu. 3 PROGRAMOVÉ VYBAVENÍ PRO SERVEROVOU ČÁST 22 sáhlé práci Route Planning Algorithms for Car Navigation pojednávající o navigaci v automobilech.[7] Používá poměrně složité programové postupy, mnohdy matematicky značně komplikované, dosahuje však lepších výsledků než obvyklé algoritmy v současnosti používané. V práci je například porovnána optimalita výsled­ ků a rychlost výpočtu proti algoritmu A* a konstatováno zlepšení o 4,5 % ve vztahu k rychlosti výpočtu a 8,5 % ve vztahu k časové náročnosti usku­ tečnění vypočtené cesty. Zásadními rysy tohoto algoritmu jsou:

– podpora souběžných hran (zde A* i Dijkstrův algoritmus selhává);

– podpora omezení odbočení (tvar křižovatky, pruhy, semafory);

– chápání grafu jako silniční sítě (například nezanedbání času nutného k projetí křižovatky);

– heuristika pro odhad vzdáleností mezi uzly;

– rozdělení grafu na několik podgrafů pro rychlejší výpočet;

– možnost vzít v potaz náročnost cesty v závislosti na denní době (na­ příklad hustota provozu, dopravní omezení).

3.5 Volba programovacího jazyka projektu

V předchozí práci (Grmela, 2008) pro sestavení převodního programu využito programovacího jazyka Perl. Práce řešila poměrně jednoduchý problém – import dat z databáze Ředitelství silnic a dálnic ČR do databáze PostgreSQL. Pro tento účel bylo využití Perlu logickou volbou vzhledem k tomu, že program pracoval převážně jen s textem, který přesouval mezi databázemi. Analýzou problému, který vyvstává se zadáním této práce, však zjistíme, že ve výsledku půjde o program podstatně složitější, který bude nejspíše zprostředkovávat propojení mezi několika programovými rozhraními a mi­ nimálně některé části by mělo být možné spouštět na různých počítačích. Původně bylo pro zpracování této práce uvažováno o jazyku C či C++ vzhledem k tomu, že jde o úlohu, která je mimořádně citlivá na čas výpočtu. Jelikož bylo však zvoleno jako jádro systému software pgRouting, který je 3 PROGRAMOVÉ VYBAVENÍ PRO SERVEROVOU ČÁST 23 sám implementován převážně v C a C++ (knihovna Boost), ve výsledku se ukázalo, že by bylo časově mnohem náročnější vytvořit programové a uživatelské rozhraní v C či C++ výměnou za jen nepatrné zrychlení výstupu. Bylo tedy rozhodnuto ponechat Perl jako hlavní jazyk práce vzhledem k jeho výborné modularitě a přenositelnosti. 4 SESTAVENÍ PŘEVODNÍKU GEOGRAFICKÝCH DAT 24

4 Sestavení převodníku geografických dat

Data, tak jak je poskytuje Ředitelství silnic a dálnic ČR a Český sta­ tistický úřad, jsou sice použitelná, jejich struktura a databázový formát však není optimální. Budeme­li chtít pro jejich zpracování využít pgRouting a PostGIS, je nutné je importovat do databáze PostgreSQL. Pro tento účel byly navrženy tři převodní programy, které zajistí vytvo­ ření vztahu mezi datovými položkami, jejich správné uložení a případně naformátování.

4.1 Návrh cílové databáze

Cílová databáze musí obsahovat zejména tabulku uzlů a úseků. Další tabulky, jako je tabulka obcí, typů křižovatek či silničních tahů umožní uživateli buď lépe nadefinovat vstupní podmínky výpočtu trasy či lépe zob­ razit výstupní data. Z provedené analýzy plyne, že databáze musí obsahovat tyto tabulky:

– cities – obce;

– districts – okresy;

– edges – úseky;

– node_types – druhy uzlů (křižovatek);

– nodes – uzly;

– regions – kraje;

– roads – čísla a typy silnic;

– system – čísla silničních tahů.

Grafická reprezentace schematu je uvedena v příloze Schéma databáze.

4.1.1 Tabulka cities (obce)

Tabulka obsahuje seznam obcí získaný z dat ČSÚ. Jde o tyto datové položky:

– id – jednoznačný identifikátor; primární klíč (integer); 4 SESTAVENÍ PŘEVODNÍKU GEOGRAFICKÝCH DAT 25

– name – označení obce (character varying 192);

– aname – označení obce bez diakritiky pro účely vyhledávání (charac- ter varying 192);

– the_geometry – informace o poloze obce (geometry);

– population – počet obyvatel (integer);

– region – kraj; cizí klíč, areas->id (integer);

– district – okres; cizí klíč, districts->id (integer);

– nearby_node – nejbližší uzel středu obce; cizí klíč, nodes->id (in- teger).

4.1.2 Tabulka districts (okresy)

Ukládá jména a čísla okresů.

– id – jednoznačný identifikátor; primární klíč (integer);

– name – název okresu (character varying 40);

– aname – název okresu bez diakritiky pro účely vyhledávání (character varying 40);

– number – unikátní číslo okresu dle ČSÚ (integer).

4.1.3 Tabulka edges (úseky)

Obsahuje seznam úseků a jejich charakteristiky.

– id – jednoznačný identifikátor; primární klíč (integer);

– from_node – zdrojový uzel úseku (integer);

– to_node – cílový uzel úseku (integer);

– cost – časová náročnost průjezdu úseku v sekundách (double preci- sion);

– reverse_cost – časová náročnost průjezdu úseku v opačném směru, v případě jednosměrného úseku rovno ­1 (double precision);

– road – silnice; cizí klíč, roads->id (integer); 4 SESTAVENÍ PŘEVODNÍKU GEOGRAFICKÝCH DAT 26

– bidirectional – informace o tom, zda je úsek obousměrný (boolean);

– canonical_name – původní název úseku z dat ŘSD (character va- rying);

– x1 – x­ová souřadnice zdrojového uzlu úseku (double precision);

– x2 – x­ová souřadnice cílového uzlu úseku (double precision);

– y1 – y­ová souřadnice zdrojového uzlu úseku (double precision);

– y2 – y­ová souřadnice cílového uzlu úseku (double precision);

– the_geometry – informace o poloze úseku (geometry);

– rule – seznam úseků, které jsou při odbočení zatíženy nějakou ča­ sovou penalizací (character varying 128);

– to_cost – časová penalizace zatížených úseků (character varying 128);

– lenght – délka úseku v metrech (double precision);

– system – silniční tah; cizí klíč, systems->id (integer).

4.1.4 Tabulka node_types (druhy uzlů)

Obsahuje informace o tom, o jaký druh křižovatky se jedná (světelná, mimoúrovňová, …).

– id – jednoznačný identifikátor; primární klíč (integer);

– code – jednopísmenný (či jednočíselný) kód druhu křižovatky (cha- racter varying 1);

– name – slovní popis druhu křižovatky (character varying).

4.1.5 Tabulka nodes (uzly)

– id – jednoznačný identifikátor; primární klíč (integer);

– node_type – druh uzlu; cizí klíč, node_types->id (integer);

– canonical_name – původní název uzlu z dat ŘSD (character va- rying); 4 SESTAVENÍ PŘEVODNÍKU GEOGRAFICKÝCH DAT 27

– the_geometry – informace o poloze uzlu (geometry);

– nearby_city – nejbližší obec; cizí klíč, cities->id (integer).

4.1.6 Tabulka regions (kraje)

– id – jednoznačný identifikátor; primární klíč (integer);

– name – název kraje (character varying 24);

– aname – název kraje bez diakritiky pro účely vyhledávání (character varying 24);

– number – číslo kraje dle ČSÚ (integer).

4.1.7 Tabulka roads (silnice)

– id – jednoznačný identifikátor; primární klíč (integer);

– code – kód silnice dle ŘSD (character varying);

– class – třída silnice; 1 = dálnice/rychlostní komunikace, 2 = první třída, 3 = druhá třída, 4 = třetí třída (smallint);

– number – číslo silnice „za lomítkem“ – II/602 (integer).

4.1.8 Tabulka systems (silniční tahy)

– id – jednoznačný identifikátor; primární klíč (integer);

– name – číslo silničního tahu „za E“ – E55 (integer).

4.1.9 Systémové tabulky PostGISu

PostGIS si do databáze ukládá geografická data, která nějakým způso­ bem popisují jednak přítomnost sloupce s datovým typem geometry v někte­ ré z „obyčejných“ tabulek a jednak disponuje seznamem souřadnicových systémů, se kterými dokáže PostGIS (prostřednictvím knihovny PROJ) pra­ covat (Souřadnicový systém, 2008).[24] Seznam a umístění tabulek disponujících sloupcem s datovým typem geometry jsou uloženy v tabulce geometry_columns. Tato tabulka se automa­ ticky aktualizuje podle toho, jak vkládáme nebo odebíráme geografická data 4 SESTAVENÍ PŘEVODNÍKU GEOGRAFICKÝCH DAT 28 do a z databáze. Její správa je zcela v rukou funkcí PostGISu, je však po­ chopitelně možné s ní manipulovat i klasikou cestou, SQL příkazy.

Souřadnicové systémy si PostGIS ukládá v tabulce spatial_ref_sys. Jde o seznam souřadnicových systému, kdy každý systém má přiřazený je­ dinečný kód6 a název. V tabulce jsou dále uloženy parametry knihovny PROJ, která se zpracováním a převody souřadnicových systémů zabývá.

4.2 Převodník dat Ředitelství silnic a dálnic ČR

4.2.1 Získání dat

Data, která převodník využívá jsou volně ke stažení na webu Ředitelství silnic a dálnic ČR – Silniční databanky Ostrava pod odkazem Využití infor­ mační základny. Data jsou aktualizována každý půlrok a jsou k dispozici ve formě něko­ lika ZIP souborů. Převodník vyžaduje pro svou práci tyto soubory:

– VUSEKY.DBF

– VUZLY.DBF

– CDMAB.DBF

– useky.shp

– uzly.shp

První tři databázové soubory se nacházejí v souboru ipasp.zip („ZIP archív s databázovými soubory“) Soubory shapefile useky.shp a uzly.shp lze získat rozbalením souborů useky.zip a uzly.zip („Shapefiles uzlů, úseků a pasportu“).

4.2.2 Zpracování dat

Převodník za pomoci modulů DBD::XBase pro vstup a DBD::Pg pro vý­ stup převede databázové soubory z formátu DBase III do databáze

6 Kódy jsou takzvaná „well­known“ čísla systémů (obvykle nazývané SRID – spatial reference ID) a jsou přidělovány státním i nestátním organizacím, případně soukromým firmám. Jejich úplný seznam včetně popisů jednotlivých systémů je k dispozici na webu http://spatialreference.org. 4 SESTAVENÍ PŘEVODNÍKU GEOGRAFICKÝCH DAT 29

PostgreSQL. Dále využije program shp2pgsql, který je součástí balíku pgRouting – ten umožní přidání polohové informace k úsekům a uzlům. Tato data se totiž v databázových souborech nenacházejí.

4.2.2.1 Převod databázových souborů

1. Ověří se přístupové údaje do databáze PostgreSQL, cílové tabulky a přítomnost zdrojových souborů. 2. Převedou se uzly.

– načtou se vstupní data z tabulky VUZLY.DBF;

– projdou se informace o úsecích, které z tohoto uzlu vycházejí nebo do něj vcházejí;

– všechny nalezené uzly se vloží do databáze.

3. Vytvoří se propojení mezi uzly pomocí úseků.

– načtou se vstupní data z tabulky VUSEKY.DBF;

– analyzuje se kód úseku;

– kód úseku se rozdělí na cílový a zdrojový uzel spolu s pří­ slušným segmentem (křižovatky jsou složeny ze segmentů);

– z databáze se dle originálních čísel uzlů najdou jejich, již uložené, ekvivalenty v novém formátu (canonical_name => id);

– pokud již úsek v databázi neexistuje (databáze ŘSD ČR ob­ sahuje duplicity), je uložen;

– k úseku jsou přidány popisné položky jako je druh silnice, délka nebo časová náročnost průjezdu7;

– nastaví se údaj o obousměrnosti či jednosměrnosti úseku, podle dopravního směru jsou případně přehozeny hodnoty položek from_node a to_node. 4. Vytvoří se seznam druhů křižovatek, ten se následně propojí s uzly.

7 Časová náročnost průjezdu je stanovena dle odhadnutých průměrných rychlostí podle jednotlivých typů silnic: dálnice/rychlostní komunikace – 110 km/h, silnice 1. třídy – 80 km/h, silnice 2. třídy – 65 km/h, silnice 3. třídy – 55 km/h. V současnosti se zanedbává údaj, zda se silnice nachází ve městě či mimo město. 4 SESTAVENÍ PŘEVODNÍKU GEOGRAFICKÝCH DAT 30

5. Propojí se silniční tahy s úseky. Každý úsek může mít přiřazeno několik (max. 4) silničních tahů, v současnosti je však přiřazován kvůli zjednodušení výstupu pouze první (a obvykle nejdůležitější) tah. Po dokončení výše uvedených kroků je databáze úseků a uzlů komplet­ ní, chybí jí však údaje o poloze těchto geografických prvků. Tyto jsou do­ plněny spuštěním dalšího programu, který tentokrát nepracuje se soubory databázovými, nýbrž shapefiles.

4.2.2.2 Převod shapefiles

1. Provede se kontrola spojení s databází PostgreSQL, přítomnost cí­ lových tabulek a zdrojových souborů.

2. Spustí se program shp2pgsql, který, jak značí jeho název, převede shapefile do sekvence SQL příkazů vložení. Program se spustí dva­ krát, na úseky i na uzly.

3. Výstupní data se importují programem psql (klient PostgreSQL) do dočasné tabulky v databázi. 4. Do databáze se přidá specifikace souřadnicového systému S­JTSK (Cenia, 2009).[2]

5. Přidají se sloupce geometrie pro tabulku edges a nodes (tyto sloupce neexistují od vytvoření databáze) a nastaví se jejich SRID na 4326 – souřadnicový systém WGS84 (World Geodetic System, 2009). [25]

6. Převedou se polohové údaje z dočasných tabulek do edges a nodes, současně s tímto převodem se provede transformace ze souřadnicové­ ho systému S­JTSK do WGS84. 7. Odstraní se dočasné tabulky. 8. Nastaví se x­ové a y­ové souřadnice úseků dle nově importované geo­ metrie. Tím je převod hotov. Databáze nyní disponuje zcela kompletními údaji pro zobrazení silniční sítě na mapě (souřadnice) i její popis (čísla silnic, druhy křižovatek, …). Dalším krokem je převedení dat Českého statistického úřadu, která nám umožní vytvoření vztahů mezi obcemi, okresy, kraji a prvky silniční sítě. 4 SESTAVENÍ PŘEVODNÍKU GEOGRAFICKÝCH DAT 31

4.3 Převodník dat Českého statistického úřadu

4.3.1 Získání dat

Stejně jako v případě dat Ředitelství silnic a dálnic ČR, jsou data Čes­ kého statistického úřadu volně k dispozici ke stažení. Je možné je získat na webových stránkách prohlížeče ÚIR­ZJS. Na těchto stránkách je třeba získat v sekci „Data za území republiky“ datový balíček (program není třeba) „ČR – úplná verze kompaktní“ ve formátu ZIP. Rozbalením je vytvořeno asi 20 databázových souborů popisujících růz­ né statistické charakteristiky České republiky. Pro účely převodníku je nutné z tohoto balíku získat jen tyto soubory:

– OKRESY.DBF;

– OBCE.DBF.

Tyto budou následně použity jako vstup do převodníku.

4.3.2 Zpracování dat

Převodník dat ČSÚ pracuje, na rozdíl od převodníků ŘSD ČR, více s daty textové povahy – data ŘSD ČR byla charakteru spíše matematického. Z toho důvodu je třeba použít dva další moduly Perlu – Text::Iconv pro pře­ kódování znakové sady a Text::Unaccent pro odstranění diakritiky. V data­ bázi totiž ukládáme data s diakritikou ve znakové sadě UTF­8, ale taktéž data bez diakritiky pro účely vyhledávání. Vstupní data jsou opět ve formátu DBase III. Jejich znaková sada je CP852, známá taktéž jako DOS/852. Postup převodu je následující: 1. Zkontrolujeme spojení s databází PostgreSQL, cílové tabulky a dostupnost zdrojových dat. 2. Převedou se okresy a kraje.

– získáme data ze vstupní tabulky okresů;

– zpracujeme a vložíme údaj o kraji, jak s diakritikou, tak i bez diakritiky;

– vložíme okresy. 4 SESTAVENÍ PŘEVODNÍKU GEOGRAFICKÝCH DAT 32

3. Převedou se obce.

– přidáme geometrii k tabulce obcí a vytvoříme příslušný index;

– získáme data ze vstupní tabulky obcí;

– ke každé obci přiřadíme ID okresu a ID kraje;

– obec uložíme.

4. Najdou se nejbližší křižovatky obcí. Tento proces používá sloupce geo­ metrie pro nalezení křižovatek v okolí deseti kilometrů od středu obcí. Tyto jsou následně seřazeny podle vzdálenosti a vybrána ta s nejnižší vzdáleností. 5. Najdou se nejbližší obce ke křižovatkám. Postup je obdobný jako v předchozím bodě, jsou nalezeny obce v okruhu deseti kilometrů od křižovatky a vybrána ta s nejnižší vzdáleností. Po dokončení převodu dat Českého statistického úřadu je databáze zce­ la kompletní a je ji možno využít pro hledání nejkratších cest pomocí aplika­ ce, která bude popsána v dalších kapitolách. Kompletní převod (všechny kroky) je časově značně náročný (zejména hledání nejbližších obcí a křižovatek), uvažujeme­li počítač s procesorem In­ tel Celeron 1,2 GHz, mluvíme o circa pěti až šesti hodinách procesorového času8.

5 Serverová část aplikace pro hledání nejkratší cesty

Aplikace jako je software pro hledání nejkratších cest jsou obvykle navr­ hovány tak, aby bylo možné tutéž aplikaci využívat z více míst, z více počíta­ čů. Tento přístup je obvykle realizován formou architektury klient­server. Serverová část často používá proprietární komunikační protokol, kterým s ní klient komunikuje. Některé projekty však raději volí cestu implementa­ ce sice vlastního protokolu, ovšem již nad protokolem standardizovaným. Tento přístup s sebou přináší výhodu snazšího propojení aplikací od různých dodavatelů a lepších možností začlenění do stávajících

8 Odečteme­li poslední dva kroky (hledání nejbližších křižovatek a obcí), sníží se časová náročnost převodu na necelou půlhodinu. 5 SERVEROVÁ ČÁST APLIKACE PRO HLEDÁNÍ NEJKRATŠÍ CESTY 33 programových balíků. Další úrovní standardizace, kterou může aplikace zvolit je jednak použít standardizovaného protokolu, nad nímž, ve vyšší vrst­ vě probíhá komunikace opět standardizovaným způsobem. Pro lepší před­ stavu – jde například o protokoly SOAP, či v poslední době velmi populární AJAX. Tyto používají standardizovaného protokolu HTTP pro přístup k webu, nad nímž dochází k přenosu XML souborů (Kosek, 2000).[11] Stejný návrh, a to jak z hlediska rozdělení na klient a server, tak z hle­ diska implementace komunikačního protokolu, byl zvolen i v této práci. Aplikace je rozdělena na CGI skript běžící takřka pod libovolným HTTP serverem (obvykle Apache) a klientský program, který je možné spustit na li­ bovolném počítači disponujícím potřebným softwarem.

5.1 Návrh komunikačního protokolu

Jelikož byla jako základní komunikační platforma vybrán Protokol pro přenos hypertextu (HTTP), bylo nutné zvážit, kterou z obvyklých cest, jež aplikace využívající tento protokol aplikují, vybrat jako nejvhodnější z ohle­ dem na následující požadavky:

– Snadná rozšiřititelnost.

– „Human­readability“ – čitelnost protokolu nejen pro automatický program, ale také pro běžného uživatele disponujícího specifikací.

– Nízká náročnost implementace.

– Podpora v nejpoužívanějších příbuzných GIS aplikacích (při použití standardizovaného formátu).

– Volná dostupnost specifikace (opět při použití standardizovaného for­ mátu). Po zvážení návrhu vlastního protokolu bylo rozhodnuto pro použití pro­ tokolu standardizovaného a již využívaného v mnoha GIS aplikacích – GPX (GPS Exchange Format). Taktéž byl zvažován konkurenční formát Keyhole Markup Language společnosti Google. KML je však spíše zaměřen na popis bodů a na zobrazení cest či tras se příliš nehodí. 5 SERVEROVÁ ČÁST APLIKACE PRO HLEDÁNÍ NEJKRATŠÍ CESTY 34

5.1.1 Popis formátu GPX

Formát GPX je vytvořen na bází XML, což jej činí jednak snadno zpra­ covatelným, ale také dobře čitelným nejen pro počítač, ale i pro člověka a to, díky použití intuitivních názvů značek, i bez znalosti specifikace. Specifika­ ce formátu je zveřejněna bezplatně jako public domain. Velkou výhodou formátu GPX je dobrá podpora v mnoha mobilních za­ řízeních (příruční GPS přístroje), stejně tak stolních aplikacích. GPX je de­ ­facto standard pro ukládání cestovních tras a je pro tento účel velmi době uzpůsoben. Taktéž je snadno rozšiřitelný – formát od počátku počítá s možností rozšíření a nabízí pro tento účel zvláštní značky. Soubor ve formátu GPX dokáže uložit informace o názvu a popisu trasy nebo cesty9, dále popis a polohu bodů, které mají být nebo byly navštíveny a mnoho dalších údajů, které lépe trasu nebo cestu přiblíží uživateli. Podrobně je specifikace formátu popsána na webu společnosti Topo­ Grafix, který je zároveň oficiálním zdrojem pro návrh implementace aplikací, které s formátem GPX nějakým způsobem pracují. Příklad běžného souboru reprezentujícího trasu je uveden v příloze Trasa z Hradce Králové do Čepelky.[18]

5.1.2 Rozšíření specifikace GPX

Jak už bylo uvedeno, je možné formát GPX snadno rozšířit – formát je na to od základu připraven a navržen tak, aby bylo možné doplnit k téměř libovolnému prvku nějaká další doplňující data. Prohlédneme­li si příklad trasy uvedený v minulé kapitole, zjistíme, že v této trase chybí mnoho údajů, které by pomohly lepšímu popisu trasy. Například není uveden bližší popis místa, kde se obec nachází (kraj, okres) či chybí údaj o vzdálenosti mezi jednotlivými místy. Tyto hodnoty je sice poměrně snadné získat dalším zpracováním v GIS softwaru, není však důvod je v souboru neuvádět hned od počátku.

9 Trasa (track) je tvořená uspořádanou posloupností bodů, které již byly navštíveny. Je k nim možné přiřadit přesný čas, kdy se tak stalo. Naproti tomu cesta (route) je tvořena posloupností bodů, které mohou být v určitém pořadí navštíveny – jde tedy o návrh trasy. Jelikož však v době vytvoření cesty není známo, kdy budou body navštíveny, není k nim možné přiřadit časový údaj. 5 SERVEROVÁ ČÁST APLIKACE PRO HLEDÁNÍ NEJKRATŠÍ CESTY 35

Vzhledem těmto nedostatkům GPX vzniklo rozšíření Mroute (tak se na­ zývá i celý programový balík, jehož se tato práce týká), které doplňuje bližší údaje jak k celé trase (tedy spíše cestě, jelikož je její výpočet proveden dopře­ du nikoli zpětně), tak k vazbě jednotlivých míst na sebe. Rozšíření Mroute umožňuje zaznamenat do GPX tyto doplňující údaje:

– druh vstupního požadavku na server (výpočet trasy, výpočet vzdá­ lenosti, informace o místech, …);

– stav požadavku, verzi softwaru serveru;

– doplňující informace o cestě;

– celkovou délku v metrech;

– celkový čas v sekundách;

– použitou výpočetní funkci (nejrychlejší trasa, nejkratší trasa, ekonomická trasa);

– zda jsou použity placené úseky silniční sítě.

– doplňující informace o počátečním a cílovém místu;

– identifikační číslo křižovatky;

– identifikační číslo obce;

– kraj;

– okres;

– počet obyvatel obce.

– doplňující informace o křižovatkách na cestě.

– identifikační číslo křižovatky;

– identifikační číslo nejbližší obce;

– kraj;

– okres;

– počet obyvatel nejbližší obce;

– třídu komunikace (dálnice/rychlostní komunikace, 1. tř.);

– číslo komunikace; 5 SERVEROVÁ ČÁST APLIKACE PRO HLEDÁNÍ NEJKRATŠÍ CESTY 36

– délku úseku k další křižovatce;

– čas potřebný pro zdolání úseku;

– číslo silničního tahu;

– pořadí křižovatky cesty.

Díky těmto rozšířením máme k dispozici mnohem více údajů o cestě a je tak možné lépe, i bez pohledu do mapy, usoudit, jak obtížná cesta bude, jak dlouhý čas zabere a jakým prostředím je vedena. Příklad cesty využívající tato rozšíření je uveden v příloze Cesta z Odrovic do Kupařovic. Důležitým rozšířením GPX jsou stavové informace serveru. Server vrací dle zadaných údajů několik možných výsledků. Obvyklým (a žádaným) vý­ sledkem je nalezená cesta a stav „ok“. Jsou však i další možnosti – na­ příklad více nalezených možných cílových obcí (pro cílovou obec „Lhota“ značný počet) či informace o nemožnosti nalézt cestu. Velkou výhodou GPX v této oblasti je, že i přesto, že soubor vygene­ rovaný softwarem Mroute obsahuje doplňující údaje o vlastním formátu, může cílový software tyto údaje ignorovat a i přesto bude mít dostatek infor­ mací pro správné zobrazení trasy.

5.2 Prerekvizity a instalace rozšíření pgRouting

pgRouting vyžaduje pro svou správnou funkčnost poměrně širokou šká­ lu aplikací a knihoven. Tyto sahají od databázového systému, přes matema­ tické knihovny až k balíku jazyku Java. Následující seznam balíků platí pro operační systém CentOS Linux ve verzi 5.2:

– postgresql, posgresql-devel;

– flex;

– java;

– proj;

– geos, geos-devel;

– postgis;

– boost, boost-devel; 5 SERVEROVÁ ČÁST APLIKACE PRO HLEDÁNÍ NEJKRATŠÍ CESTY 37

– slang, slang-gevel, compat-slang;

– gaul-devel (ze zdrojových kódů, neexistuje balík);

– gcc, gcc-c++, make, cmake;

– CGAL (ze zdrojových kódů, neexistuje balík).

Po instalaci všech výše uvedených balíků (podrobnější postup uveden na webových stránkách pgRoutingu) je možné nakonec přeložit rozšíření pgRouting a naplnit databázi počátečními daty nutnými pro správnou funk­ ci PostGISu a pgRoutingu (funkce, tabulka souřadnicových systémů).[14] 1. Stáhnout buď stabilní verzi pgRoutingu z domovské stránky nebo vy­ užít Subversion pro stažení verze vývojové.

2. Pomocí cmake provést překlad (volby pro povolení rozšíření jako na­ příklad řešení Problému obchodního cestujícího jsou uvedeny v README.cmake).

3. Nainstalovat příkazem make install.

4. Vytvořit uživatele databáze PostgreSQL příkazem createuser -P uzivatel (tento bude mít přístup k databázi mroute).

5. Vytvořit databázi příkazem createdb -U uzivatel mroute.

6. Přidat podporu jazyka PL/PGSQL do této databáze createlang - U uzivatel plpgsql mroute. 7. Importovat do databáze funkce PostGIS příkazy. psql -U uzivatel -f /usr/share/pgsql/postgresql/ contrib/lwpostgis.sql mroute psql -U uzivatel -f /usr/share/pgsql/postgresql/ contrib/spatial_ref_sys.sql mroute 8. Přidat funkce pgRoutingu.

psql -U uzivatel -f /usr/share/postlbs/routing_core.sql mroute psql -U uzivatel -f /usr/share/postlbs/ routing_core_wrappers.sql mroute psql -U uzivatel -f /usr/share/postlbs/ routing_topology.sql mroute 5 SERVEROVÁ ČÁST APLIKACE PRO HLEDÁNÍ NEJKRATŠÍ CESTY 38

Po provedení těchto příkazů je základní obsah databáze na svém místě. Je však třeba jej ještě doplnit o tabulkovou strukturu a funkce Mroute. Tak­ též je třeba provést instalaci Mroute samotného.

5.3 Instalace serverové části aplikace

Serverová komponenta předpokládá pro svou funkci správně nain­ stalovaný některý z webových serverů podporujících CGI – například Apache či Lightttpd. Dalšími požadavky jsou tyto balíky:

– perl;

– perl-CGI-Application;

– perl-DBI;

– perl-DBD-Pg;

– perl-DBD-Xbase;

– perl-Getopt-ArgvFile;

– perl-Getopt-Long;

– perl-Error;

– perl-Switch;

– perl-Text-Iconv;

– perl-Text-Unaccent;

– perl-XML-Writer.

Instalací těchto balíků je vytvořeno běhové prostředí jak pro server samotný, tak i pro převodníky zdrojových souborů. Samotná instalace serveru je snadná.

1. Z instalačního balíku mroute-server je třeba přesunout soubor mrou- te a adresář MrouteServer do adresáře, kde je možno spouštět CGI skripty. Obvykle tedy do /var/www/cgi-bin/. 2. Je třeba importovat do databáze funkce a strukturu tabulek Mroute

psql -U uzivatel -f mroute-func.sql mroute psql -U uzivatel -f mroute-tables.sql mroute 5 SERVEROVÁ ČÁST APLIKACE PRO HLEDÁNÍ NEJKRATŠÍ CESTY 39

Tím je instalace serveru dokončena.

5.4 Implementace serverové části aplikace

Serverová část aplikace je implementována formou CGI skriptu složené­ ho z několika modulů – hlavního, generátoru GPX souborů a modulu výji­ mek.

5.4.1 Volba algoritmu pro hledání nejkratší cesty

Jak již bylo uvedeno v kapitole 3.4 Základní principy výpočtu nejkratší cesty v softwaru pgRouting, nabízí rozšíření pgRouting tři možnosti pro hle­ dání nejkratší cesty v geografických datech silniční sítě (či jiného grafu).

– Dijkstrův algoritmus

– výhody

– hledání z uzlu do uzlu;

– snadné použití;

– nevyžaduje v databázi sloupec s geometrií.

– nevýhody

– nedokáže pracovat se souběžnými úseky;

– značná časová a paměťová náročnost při rozsáhlém grafu;

– nepodporuje omezení odbočení.

– algoritmus A*

– výhody

– hledání z uzlu do uzlu;

– vyzkoušená implementace (knihovna Boost);

– dobrý výkon i při rozsáhlém grafu.

– nevýhody

– nedokáže pracovat se souběžnými úseky; 5 SERVEROVÁ ČÁST APLIKACE PRO HLEDÁNÍ NEJKRATŠÍ CESTY 40

– vyžaduje v databázi sloupec s geometrií;

– nepodporuje omezení odbočení.

– algoritmus Shooting Star

– výhody

– dokáže pracovat se souběžnými úseky;

– optimalizován na velmi rozsáhlé grafy;

– podporuje omezení odbočení.

– nevýhody

– složité použití;

– hledání z úseku do úseku;

– nevyzkoušená implementace.

Jelikož je k dispozici ke každém úseku i uzlu údaj o poloze (geometrii), je rozumné přímo vyřadit Dijkstrův algoritmus, neboť je, při použití rozsáh­ lého grafu, příliš náročný a současně poskytuje výsledky pomaleji, jelikož nepoužívá žádné odhadní metody kalkulující s polohou zdrojového a cílové­ ho uzlu. Rozhodování mezi dvěma dalšími algoritmy je podstatně složitější – má vyšší váhu výhoda v podobě vyzkoušené implementace nebo optimalizace pro rozsáhlé grafy spolu s podporou souběžných úseku? Uvážíme­li situaci v obvyklé silniční síti, snadno dospějeme k názoru, že výskyt souběžných komunikací je poměrně častý a tak by asi nebylo rozumné, kdyby měl program uživateli doporučit jízdu s častými odbočeními namísto jízdy přímé. Zdánlivým problémem je i hledání z úseku do úseku algoritmu Shooting Star. Ve skutečnosti však nejde o nic závažného. Uvažujeme­li, že každý úsek je tvořen dvěma body – počátečním a koncovým – zjistíme, že pro zís­ kání úseku příslušícímu k určitému uzlu, je nutné pouze zvolit jeden z úse­ ků, které mají tento uzel jako koncový nebo počáteční. Z výše uvedeného plyne doporučení zvolit algoritmus Shooting Star. Je­ likož však Shooting Star i A* přijímá na vstupu stejné údaje, je možné tyto algoritmy kdykoli zaměnit a tak si ověřit správnost uvedených domněnek. 5 SERVEROVÁ ČÁST APLIKACE PRO HLEDÁNÍ NEJKRATŠÍ CESTY 41

5.4.2 SQL rozhraní rozšíření pgRouting

pgRouting umožňuje získání údajů o nejkratší cestě v prostředí SQL za použití několika základních funkcí. Uvažujeme­li pouze algoritmus Shoo­ ting Star, je deklarace příslušné funkce následující:

CREATE OR REPLACE FUNCTION shortest_path_shooting_star (sql text, source_id integer, target_id integer, directed boolean, has_reverse_cost boolean) RETURNS SETOF path_result

kde path_result je definován jako CREATE TYPE path_result AS (vertex_id integer, edge_id integer, cost float8);

a sql je SQL dotaz SELECT id, source, target, cost, x1, y1, x2, y2, rule, to_cost FROM edges

Funkce shortest_path_shooting_star má tedy na vstupu SQL dotaz, který vrací seznam úseků spolu s jejich zdrojovým a cílovým uzlem, časem nutným pro projetí úseku, souřadnicemi počátku a konce, omezeními odbo­ čení a časem, který trvá odbočení do dalšího úseku. Dále je vstupní hodnotou počáteční úsek cesty, cílový úsek cesty, údaj o tom, zda graf ob­ sahuje jednosměrné úseky a zda jsou tyto úseky ohodnoceny nějakým ča­ sovým údajem. Výstupem volání funkce je seznam uzlů, úseku a času nutného pro zdolání úseku. V případě Mroute, kdy jsou názvy sloupců odlišné od názvů předpoklá­ daných v dokumentaci pgRoutingu, by takový dotaz na cestu z úseku 10 do úseku 20 mohl vypadat takto: SELECT * FROM shortest_path_shooting_star ('SELECT id, from_node AS source, to_node AS target, cost, x1, y1, x2, y2, rule, to_cost FROM edges', 10, 20, true, true); Je zřejmé, že z uživatelského hlediska není syntaxe takového volání nikterak vhodná a bylo by vhodnější toto volání vložit do funkce, která bude mít na výstupu seznam podobný jako v případě vnitřní funkce pgRoutingu shortest_path_shooting_star, avšak na jejím vstupu budou pouze dvě 5 SERVEROVÁ ČÁST APLIKACE PRO HLEDÁNÍ NEJKRATŠÍ CESTY 42 hodnoty – počáteční a cílový uzel cesty. Funkce, která tento převod zpro­ středkovává se nazývá MR_GetRoute a je součástí balíku funkcí, které se in­ stalují společně se serverovou částí. Deklarace funkce je následující:

CREATE OR REPLACE FUNCTION MR_GetRoute (int, int) RETURNS SETOF MR_Route AS $$ DECLARE r MR_Route; BEGIN BEGIN DELETE FROM tmp_route; EXCEPTION WHEN others THEN CREATE TEMPORARY TABLE tmp_route (edge_id int, "cost" float, id serial); END; INSERT INTO tmp_route (SELECT edge_id, cost FROM shortest_path_shooting_star ('SELECT id, from_node AS source, to_node AS target, cost, reverse_cost, x1, y1, x2, y2, rule, to_cost FROM edges AS edges_r', MR_EdgeNearNode ($1), MR_EdgeNearNode ($2), true, true)); FOR r IN SELECT t.id, t.edge_id, n.id, t.cost FROM tmp_route t LEFT JOIN edges e ON t.edge_id = e.id LEFT JOIN nodes n ON e.from_node = n.id LOOP RETURN NEXT r; END LOOP; RETURN; END; $$ LANGUAGE plpgsql;

kde MR_Route je definována jako 5 SERVEROVÁ ČÁST APLIKACE PRO HLEDÁNÍ NEJKRATŠÍ CESTY 43

CREATE TYPE MR_Route AS (id int, edge_id int, node_id int, "cost" float);

a funkce MR_EdgeNearNode má deklaraci CREATE OR REPLACE FUNCTION MR_EdgeNearNode (int) RETURNS edges.id%TYPE AS $$ SELECT id FROM edges WHERE from_node = $1 OR to_node = $1 LIMIT 1; $$ LANGUAGE SQL;

„Obalová“ funkce MR_GetRoute má za úkol vytvořit nejprve dočasnou tabulku, do které jsou následně vloženy výsledky ještě předtím, než jsou předány na výstup. Do této dočasné tabulky jsou vkládány postupně, tak, jak je vrací funkce shortest_path_shooting_star a je u nich zaznamenáno pořadové číslo10. Dále je zajištěno propojení úseků ve výsledku s tabulkou uzlů11 a následné vrácení obsahu dočasné tabulky uživateli. Výsledkem volání je uspořádaný seznam uzlů a úseků spolu s jejich ča­ sovým nákladem.

5.4.3 Hlavní modul

Tento modul je základním modulem, který se přímo zabývá spuštěním a během aplikace prostřednictvím modulu Perlu CGI::Aplication. Tento umožňuje s poměrně malou kódovou základnou vytvořit pokročilou CGI aplikaci. Usnadňuje práci se vstupními parametry, proměnnými serveru i prostředí a taktéž umožňuje snáze předávat výstup do uživatelova webové­ ho prohlížeče. Právě v tomto modulu probíhá analýza vstupních parametrů jako je ná­ zev počáteční a cílové obce a doplňující údaje pro hledání cesty. Postup, ja­ kým skript pracuje závisí na vstupních datech, obvykle je však následující:

10 Jelikož databázové rozhraní negarantuje pořadí vrácených výsledků z databáze a samotná funkce shortest_path_shooting_star vrací výsledky bez jakéhokoli třídícího klíče (pořadového čísla), je nutné výsledkům přiřadit klíč ex post. 11 Současná implementace funkce shortest_path_shooting_star obsahuje chybu, kvůli které nemusí být identifikační čísla vrácených úseků správná. Čísla uzlů však správná jsou, snadno je tedy možné tento problém obejít. 5 SERVEROVÁ ČÁST APLIKACE PRO HLEDÁNÍ NEJKRATŠÍ CESTY 44

1. Jsou načtena nastavení databáze z konfiguračního souboru. 2. Podle typu požadavku se buď vyhledá cesta (viz dále) nebo jen zobrazí stav serveru – dostupnost databáze. 3. Jsou ověřena vstupní data regulárními výrazy pro české názvy obcí. 4. Podle toho, zda hledáme obce podle přesného názvu (případně ID obce) nebo jen podle části, jsou provedeny příslušné dotazy do data­ báze. 5. Jestliže nebylo nalezeno více obcí se stejným (přesný název) nebo podobným (část názvu) názvem, jsou získány jejich údaje jako název, poloha, kraj či okres. 6. Údaje o počátečním a cílovém bodu jsou zapsány do souboru GPX. 7. Podle toho, zda je požadavek na zjištění cesty nebo pouze vzdálenosti je buď získán seznam křižovatek (a jejich údajů) na cestě nebo jen cestovní vzdálenost od počáteční k cílové obci trasy. 8. Na výstup (do prohlížeče či klienta) je vrácen GPX soubor buď s tra­ sou či se stavovou informací o tom, proč se trasu nepodařilo získat. Datový soubor GPX, který je na výstupu předán rozhraním CGI webové­ mu serveru a následně prohlížeči či klientu, obsahuje všechny dostupné údaje o cestě a je jej možné přímo použít v libovolné aplikaci podporující for­ mát GPX.

5.4.4 Modul generátoru GPX a výjimek

Moduly generátoru GPX a výjimek se připojují k hlavnímu modulu. Generátor GPX používá modul Perlu XML::Writer pro transformaci datové struktury reprezentující cestu na platný soubor GPX. Implementuje několik metod sloužících pro vkládání dat do této struktury. Nakonec, voláním me­ tody getGPX(), proběhne samotná transformace, na jejímž výstupu je řetě­ zec obsahující soubor GPX. Modul výjimek tvoří datovou strukturu použitou v hlavním modulu, kte­ rá zajišťuje korektní zpracování případných běhových chyb či informací da­ tabázového stroje a předání informací o těchto událostech uživateli – opět, zapsáním do GPX souboru. 6 KLIENTSKÁ ČÁST APLIKACE PRO HLEDÁNÍ NEJKRATŠÍ CESTY 45

6 Klientská část aplikace pro hledání nejkratší cesty

Bez klientské části aplikace by nebyl balík programu pro hledání nejkratší cesty kompletní. Tato část zprostředkovává uživatelský vstup serveru a vrací naopak nalezenou cestu či stavové informace uživateli ve snadno čitelné podobě.

6.1 Instalace klientské části aplikace

Instalace klienta je podstatně jednodušší než v případě serveru. Díky mnohem nižší komplexnosti programu je množství závislostí sníženo na mi­ nimum. Pro korektní fungování klienta je nutné mít nainstalovány alespoň tyto balíky:

– perl;

– perl-Getopt-Long;

– perl-Getopt-ArgvFile;

– perl-XML-Simple;

– perl-XML-Parser;

– perl-Pod-Usage;

– perl-LWP-Simple;

– perl-Error;

– perl-Switch.

Po nainstalování těchto balíků je již možné aplikaci přímo spustit, žádné další kroky pro její zprovoznění nejsou nutné.

6.2 Implementace klientské části aplikace

I postup práce programu je v případě klienta podstatně jednodušší. Jeho hlavním úkolem je jen stažení GPX souboru z příslušného serveru a zpracování obsahu. Postup je možno shrnout do následujících bodů: 6 KLIENTSKÁ ČÁST APLIKACE PRO HLEDÁNÍ NEJKRATŠÍ CESTY 46

1. Jsou zpracovány volby z konfiguračního souboru a příkazového řádku. 2. 2. V případě jejich správnosti je server Mroute požádán o dodání GPX souboru s příslušnou cestou. 3. Soubor je buď dále zpracován (standardní chování) nebo rovnou vy­ psán na příkazový řádek. 4. Je zjištěno, zda jde o platný soubor Mroute GPX. 5. Je ověřen stavový kód obsažený v souboru a buď je zpracování sou­ boru přerušeno (některá z obcí nebyla nalezena, neexistuje mezi nimi cesta, chybné znaky na vstupu, …) nebo pokračuje převodem cesty z XML. 6. Jsou čteny jednotlivé uzly cesty a zobrazovány k nim údaje na stan­ dardní vstup. 7. Po vypsání cílového uzlu cesty jsou vypsány další údaje o cestě jako je její délka v kilometrech či časový odhad náročnosti. Uživatel tedy při zadání platných a konkrétních dat získá textový plán cesty mezi dvěma zadanými obcemi spolu s bližšími údaji jednak o obcích samotných a jednak o cestě jako celku.

7 Návod k použití aplikace

Jakmile jsou splněny veškeré náležitosti funkce jak serverové, tak kli­ entské části aplikace je možno přikročit k importu dat do databáze a ná­ slednému testu funkčnosti.

7.1 Import dat do databáze PostgreSQL

K importu dat využijeme oba převodníky popsané v předchozích kapi­ tolách. Programy budou ke své funkci vyžadovat datové soubory stanovené v kapitolách 4.2.1 Získání dat v případě převodníku dat Ředitelství silnic a dálnic a 4.3.1 Získání dat v případě převodníku dat Českého statistického úřadu. Předpokladem je pochopitelně funkční a běžící databázový server PostgreSQL. Postup importu je následující: 7 NÁVOD K POUŽITÍ APLIKACE 47

1. Upravte ve skriptech mroute-import-rsd-data.pl, mroute-import- -rsd-geometry.pl a mroute-import-csu.pl údaje pro připojení k da­ tabázi dle vzoru: my $SERVER = 'název hostitele databázového serveru'; my $DATABASE = 'název cílové databáze'; my $USER = 'databázový uživatel'; my $PASSWORD = 'heslo databázového uživatele'; my $XXX_DIR = 'adresář, kde jsou umístěny zdrojové soubory'; 2. Spusťte převod dat ŘSD ČR příkazem (skript je umístěn v aktuálním adresáři) ./mroute-import-rsd-data.pl. 3. Skript bude informovat o svém postupu a když skončí, zobrazí infor­ maci o úspěšném převodu. 4. Jakmile je krok dokončen, spusťte převod polohových dat příkazem spuštění skriptu ./mroute-import-rsd-geometry.pl. 5. Stejně jako v předchozím případě bude skript informovat o výsledku převodu.

6. Na závěr spusťte převod dat ČSÚ příkazem ./mroute-import-csu.pl. 7. Převod dat ČSÚ potrvá velmi dlouhou dobu a o svém ukončení bude informovat. Po těchto krocích je v cílová databáze naplněna všemi daty nutnými pro správnou funkci serveru a klienta.

7.2 Nastavení serveru

Jakmile je server zkopírován v cílovém adresáři a je dostupný jako CGI skript, posledním úkonem, který je nutno před jeho kompletním zprovozně­ ním provést, je uložit nastavení serveru tak, aby měl k dispozici údaje nutné pro připojení k databázi.

Standardním místem pro uložení nastavení je soubor /etc/mroute.conf, ve kterém je třeba uvést následující konfigurační hodnoty:

--myself=URI serveru, na kterém je aplikace spuštěna (např. http://neco.cz či http://localhost) --database-server=hostitel databázového serveru 7 NÁVOD K POUŽITÍ APLIKACE 48

--database-database=název databáze --database-user=databázový uživatel --database-password=heslo databázového uživatele Komentáře k hodnotám je možno provádět uvedením znaku # před jejich obsah.

7.3 Použití klienta

Klientský program mroute-client je možné použít přímo bez na­ stavování, je však nutné mu při každém spuštění předávat adresu serveru, kterého se má dotazovat. Z toho důvodu je lepší, podobně jako v případě serveru, vytvořit klientu konfigurační soubor se seznamem voleb. Konfigurační soubor je při spuštění automaticky vyhledáván v domovské složce aktuálního uživatele a jeho název je .název-klienta. V případě, že se tedy klient jmenuje mroute-client, bude název konfigu­ račního souboru .mroute-client.

7.3.1 Spouštěcí volby klienta

Klientský program přijímá několik voleb příkazové řádky, které upravují jeho chování a výstupní formát.

– -f, --from [řetězec] (povinná)

Název nebo identifikační číslo počáteční obce (nerozlišují se malá a velká písmena ani použití diakritiky).

– -t, --to [řetězec] (povinná)

Název nebo identifikační číslo cílové obce (nerozlišují se malá a velká písmena ani použití diakritiky).

– -u, --uri [řetězec] (povinná)

Adresa cílového serveru nebo zdrojového Mroute GPX souboru na webu.

– -g, --gpx

Při použití této volby je získaný GPX soubor přímo předán na stan­ dardní výstup bez zpracování. 7 NÁVOD K POUŽITÍ APLIKACE 49

– -d, --distance-only

Je­li aktivována tato volba, program na výstup vypíše pouze vzdá­ lenost mezi počáteční a cílovou obcí.

– -e, --exact-match

Aktivací této volby program vypne hledání částečného názvu na serveru. Tedy například, pokud nebude tato volba zapnuta, bude na dotaz „Brno“ nalezeno kromě obce „Brno“ i obec „Úsobrno“. Ovlivňuje jak název počáteční, tak cílové obce. Volba je užitečná, pokud je záměrem specifikovat přesný název obce.

– -v, --verbose

Použití této volby zvýší množství informací vypisovaných na výstup.

– -h, --help

Zobrazí integrovanou nápovědu.

– -i, --info, --version

Vypíše informaci o verzi programu a skončí. Výstup programu (názvy obcí, krajů a okresů) je v UTF­8, pro správnou funkci je tudíž nutné, aby měl systém, na němž je program spouštěn, na toto kódování nastavený terminál.

7.3.2 Příklady příkazů klienta

Klient podle zadaných parametrů vypisuje na standardní vstup různé údaje. Několik příkladů příkazů, které je možno použít je uvedeno níže.

– „najdi cestu z Prahy do Brna“;

mroute-client -u http://srv/mroute -e -f Brno -t Praha

– „najdi cestu z nějaké Lhoty do nějaké Nové Vsi“;

mroute-client -u http://srv/mroute -f Lhota -t 'Nová Ves'

– „najdi vzdálenost z Ostravy do Prahy a ulož ji do souboru“.

mroute-client -u http://srv/mroute -f Ostrava -t Praha -ed > vystupni-soubor 7 NÁVOD K POUŽITÍ APLIKACE 50

Výstup příkladu „najdi cestu z Prahy do Brna“ je uveden v příloze Příklad použití klienta. Grafická reprezentace výstupu je uvedena v příloze Zobrazení cesty z Brna do Prahy vypočtené vytvořenou aplikací. Kvalitu vý­ stupu je možné srovnat pohledem na přílohu Zobrazení cesty z Brna do Prahy vypočtené Google Maps.

8 Diskuse

8.1 Posouzení výsledků

Aplikační balík, který byl v této práci vytvořen poskytuje velkou část funkcionality, kterou pgRouting a PostGIS nabízí. Přesto mnoho možností zůstává nevyužito. Jedním z hlavních faktorů je nedostatečná analýza vstupních dat pro vyhodnocení cenovou funkcí. Momentálně provádí prosté vyhodnocení typu komunikace bez bližší analýzy dalších parametrů, které mohou mít na pře­ pravní rychlost (resp. čas nutný ke zdolání úseku) vliv. Jde například o tyto faktory:

– umístění komunikace ve městě či mimo město;

– počet pruhů komunikace;

– rychlostní omezení úseku;

– tvar osy komunikace;

– podrobnější rozlišení druhu úseku;

– počet křížení na trase;

– typ křížení (např. světelná nebo mimoúrovňová křižovatka).

Tyto a mnoho dalších, méně významných faktorů, mohou přepravní rychlost mnohdy i značně ovlivnit. Časový odhad, který program poskytuje je tedy v současném stavu možno brát pouze jako orientační. Stejně tak i cesta, která je programem vypočítána, mnohdy nevykazuje charakteristiky trasy optimální – příkladem je ilustrace v příloze Zobrazení cesty z Brna do Prahy pomocí Google Maps. Z ilustrace je zřejmá navržená zbytečná smyčka kolem Prahy místo přímé jízdy do centra. Tato smyčka byla 8 DISKUSE 51 programem navržena právě z důvodů nepřesného výstupu cenové funkce. Objezd části Prahy se díky této nepřesnosti jevil být výhodnější než přímá cesta do centra. Dalšími nedostatky, které nejsou momentálně náležitě ošetřeny, je na­ příklad zbytečný informační výstup při jízdě po komunikaci, jež je rozdělena mnoho úseků. Uživatel i přesto, že není navrženo odbočení z této komunika­ ce, je informován stejným způsobem jako kdyby k odbočení mělo dojít. Tak­ též není žádným způsobem implementována funkcionalita poskytující infor­ mace o tvaru křižovatky, počtu pruhů či žádaném směru odbočení. Naproti tomu je možné konstatovat, že použití interpretovaného jazyka, jako je Perl, žádným zásadním způsobem nesnižuje výkonnost aplikace. Tento výsledek je možno přičíst tomu, že většina výpočetně náročné funkcio­ nality je implementována jazykem nižší úrovně – C či C++.

8.2 Porovnání s komerčními systémy

Chceme­li provést porovnání aplikačního balíku vytvořeného v rámci této práce, je třeba zvolit vhodné charakteristicky, jež budeme porovnávat. Je třeba uvažovat odlišnou stavbu balíku (výstup v XML + konzolový klient) proti komerčním systémům (obvykle přímo výstup ve formě obrázků a textu, případně javascriptových objektů). Vzhledem k rozdílnosti aplikačního prostředí není možné snadno po­ rovnat výkonnost vytvořené aplikace oproti komerčním mapovým službám. Komerční služby jsou totiž obvykle provozovány na velmi výkonných apli­ kačních serverech, mnohdy složených z velkého množství počítačů (Google Maps), zatímco vytvořená aplikace je určena pro provozování zejména na běžném stolním počítači, případně malém serveru. Je tedy třeba se zaměřit nikoli na porovnání výkonnosti, nýbrž na sub­ jektivní rychlost (posouzení koncovým uživatelem), délku a pohodlnost cesty a riziko zdržení na cestě (například průjezd velkým městem). Taktéž je nutno brán ohled na funkcionalitu a možnost rozšíření. Pro porovnání systému hledání nejkratší cesty bylo vybráno několik po­ pulárních webových služeb s odpovídajícím rozsahem funkcionality a geo­ grafických dat.

– Mapy.cz (Seznam, http://www.mapy.cz); 8 DISKUSE 52

– Amapy.cz (Centrum, http://www.amapy.cz);

– Google Maps (Google, http://maps.google.com);

– Yahoo! Maps (Yahoo!, http://maps.yahoo.com);

– ViaMichelin (Michellin, http://www.viamichelin.com).

Do těchto služeb byl následně zadán dotaz na vyhledání nejrychlejší cesty z Hradce Králové do Českých Budějovic (kvůli různorodosti komunika­ cí na spojnici měst). Následně byl výsledek dotazu zhodnocen po stránce několika kritérií. Délka udaná v kilometrech a časových jednotkách byla hodnocena tím pozitivněji, čím byla hodnota nižší. Další tři faktory byly zhodnoceny subjek­ tivně. Pohodlnost je dána tvarem navržené trasy a poměrem používání silnic vyšších tříd oproti silnicím tříd nižších. Riziko zdržení zohledňuje šanci zdr­ žení na trase například vlivem průjezdu velkým městem. Rychlost služby hodnotí čas od odeslání požadavku do obdržení výsledku. Subjektivně hodnocené parametry navržené trasy byly oznámkovány od 1 do 10, kdy jed­ na značí výsledek nejhorší a 10 výsledek nejlepší. Stejný dotaz byl zadán i do aplikace vypracované v rámci této práce. Je­ likož aplikace nedisponuje grafickým rozhraním, byla navržená cesta zob­ razena pomocí nástroje GPS Visualizer a provedeno srovnání vykreslené cesty.[17]

název služby délka [km] délka [HH:MM] pohodlnost riziko zdržení rychlost služby Mapy.cz 254 03:29 8 6 7,5 Amapy.cz 217 02:39 6 8 4 Google Maps 267 03:23 4 6 8 Yahoo! Maps 254 03:14 8,5 6,5 7 ViaMichelin 256 03:06 8,5 6,5 5 Mroute 227 02:42 6,5 8,5 3 Tabulka 1: Srovnání parametrů navržené cesty z Hradce Králové do Českých Budějovic.

Tabulka 1 tyto výsledky sumarizuje. Sytě červený podklad buňky sym­ bolizuje nejhorší hodnotu (hodnoty), oranžový druhou nejhorší hodnotu nebo hodnoty. Světle zelený výsledek (výsledky) je nejlepší změřený, tmavě zeleným podbarvením je signalizován výsledek či výsledky na druhém místě. 8 DISKUSE 53

Je patrné, že realizovaná aplikace si v porovnání s komerčními systémy vede velmi dobře. Jediným parametrem, ve kterém zaostává je rychlost služ­ by. To je však, jak už bylo zmíněno, dáno zaměřením aplikace zejména na použití v menších systémech, nikoli pro miliony uživatelů jako v případě výše uvedených komerčních služeb. Překvapivým výsledkem tohoto srovnání jsou velmi různorodé hodnoty délky cesty, zejména co se týče časového ohodnocení. Tyto odchylky jsou dány zejména odhadními algoritmy, taktéž však faktorem, který cestu pod­ statně ovlivňuje – plánováním přes Hlavní město Praha. Služby, navrhující kratší cestu obvykle provedly plánování mimo Hlavní město, často i mimo dálnice (nejvýrazněji Google Maps) za cenu kratší délky v kilometrech a menšího rizika zdržení, avšak s delší cestou v časovém vyjádření. Vytvořená aplikace odhadla jak čas s odchylkou ­12 % a vzdálenost ­15 % od průměrné hodnoty dotazovaných komerčních aplikací. Pohodlnost cesty byla 4 % pod průměrnou hodnotou, riziko zdržení nejnižší naměřené, stejně tak však rychlost služby.

9 Závěr

Cílem práce bylo vytvoření rozhraní, které by uživateli umožňovalo snadné zjištění nejkratší cesty silniční sítí mezi dvěma libovolnými sídly v České republice. Toto rozhraní mělo být realizováno jako terminálová aplikace, umožňující nejen prosté spuštění uživatelem, ale i opakované au­ tomatizované použití. Vedlejším cílem bylo vytvoření takové aplikace, která by umožnila provádění dotazů nejen na počítači, kde jsou dostupná prohle­ dávaná data, ale i na počítačích jiných, propojených s hlavním strojem počí­ tačovou sítí.

Prvním krokem bylo získání a převod dat do formy, která umožní prove­ dení příslušných analýz a výpočet nejkratší cesty. Jako zdrojová data byly vybrány datové balíky Ředitelství silnic a dálnic ČR a Českého statistického úřadu. Data, ač kvalitativně i kvantitativně dostačující, bylo nutné do značné míry upravit a optimalizovat, aby je bylo možno použít jako zdrojová data rozšíření PostGIS a pgRouting. Též bylo nutné překonat problém faktické nedostupnosti dokumentace k datům Ředitelství silnic a dálnic České republiky. 9 ZÁVĚR 54

Dalšími kroky byl návrh struktury a implementace tabulek a funkcí da­ tabáze. Byla vytvořena vrstva nad funkcemi poskytovanými pgRoutingem a tato vrstva byla následně použita v dalším kroku – návrh a implementace samotného programového balíku. Byly vytvořeny dvě nezávislé části aplika­ ce – serverová a klientská. Serverová část aplikace poskytuje data ve stan­ dardizovaném formátu. Tato data je tak možno použít i v dalších geoinfor­ mačních aplikacích. Klientská část je reprezentována programem, který vznese dotaz na server a následně zpracuje data, která jsou mu serverem poskytnuta. Výstupem programu je textový seznam křižovatek a úseků trasy s jejich bližším popisem a statistickými informacemi. Bylo zjištěno, že návrh cenové funkce, která uvažuje jako vstupní koefi­ cienty pouze délku úseku a druh komunikace, je dostatečný a výsledky, které přináší pgRouting, resp. zvolený algoritmus Shooting Star, jímž je funkcionalita hledání nejkratší cesty realizována, jsou velmi dobré, porovna­ telné s komerčně dostupnými řešeními. Nebylo prokázáno, že by neově­ řenost algoritmu Shooting Star měla za následek jakékoli snížení kvality vý­ stupních dat, případně, že by kvalita výstupu kolísala. Dále byly zjištěny rozsáhlé možnosti dalšího rozšíření právě díky použití algoritmu Shooting Star a systému řízení báze dat PostgreSQL s rozšířením PostGIS. Tento algoritmus a databázový systém disponuje funkcionalitou, která umožňuje vytvořit velmi kvalitní aplikaci pro plánování cesty, a to včetně všech doplňků běžně dostupných v komerčních navigačních za­ řízeních a aplikacích. Porovnáním výstupů z komerčních aplikací (například Mapy.cz či Google Maps) a aplikace vytvořené v rámci této práce byla zjištěna jen zanedbatelná odchylka v přesnosti výpočtu vzdálenosti. Navržená trasa se mnohdy zcela shodovala s výsledky poskytnutými těmito komerčními systémy. Jak klientská, tak serverová část aplikace včetně převodníků a in­ stalačních skriptů databázové struktury, je zpřístupněna jednak na při­ loženém CD a jednak na webových stránkách projektu http://mroute.eu. Programový balík je zveřejněn pod licencí GNU General Public Licence 3 a je jej tedy možné volně šířit a upravovat v rámci podmínek této licence. 9 ZÁVĚR 55

Seznam použité literatury

A* search algorithm in Wikipedie [on­line], 2009 [cit. 2009­04­13]. Dostupný z WWW: BOŘÍK, Milan ­­ HONZÍK, Vojtěch. Open source GIS ­­ funkce v prostředí PostGIS, tvorba vlastních funkcí a grafických výstupů in 25. konference o PC grafice, Plzeň: Západočeská univerzita v Plzni, 2005. Cenia LabGIS. Vložení korektní projekce S­JTSK do PostGIS. Cenia [on­line], 2009. [cit. 2009­03­12]. Dostupný z WWW: Český statistický úřad. Prohlížeč UIR­ZSJ. [on­line], 2009. [cit. 2009­04­10]. Dostupný z WWW: DEVELIN, Keith. Problémy pro třetí tisíciletí ­­ Sedm největších nevyřešených otázek matematiky. Praha: Argo, Dokořán, 2005. 269 s. ISBN 80­7363­016­8 DUBOIS, Paul. MySQL profesionálně. Brno: Computer Press, 2003. 1072 s. ISBN 80­8659­341­X Environmental Systems Research Institute. ESRI Shapefile Technical Description., Redlands, CA, USA: Environmental Systems Research Institute, 1998. FLINSENBERG, Ingrid C.M.. Route Planning Algorithms for Car Navigation., Eindhoven, Nizozemsko: Technische Universiteit Eindhoven, 2004. Geobase in Wikipedie [on­line], 2009 [cit. 2009­04­21]. Dostupný z WWW: Geospatial Consortium. OpenGIS Implementation Specification for Geographic information ­­ Simple feature access ­ Part 1: Common architecture., Wayland, Maryland, USA: Geospatial Consortium, 2006. GRMELA, Jan. Převodník geografických dat., Brno: Mendelova zemědělská a lesnická univerzita v Brně, 2008. HLINĚNÝ, Petr. Teorie grafů., Brno: Masarykova univerzita, 2008. KOSEK, Jiří. XML pro každého. Praha: Grada Publishing, 2000. 164 s. ISBN 80­7169­860­1 LACKO, Luboslav. Web a databáze. Brno: Computer Press, 2001. 250 s. ISBN 80­7226­555­5 9 ZÁVĚR 56

MOMIJAN, Bruce. PostgreSQL: praktický průvodce. Brno: Computer Press, 2003. 402 s. ISBN 80­7226­954­2 Orkney, Inc. Installation ­­ CentOS 5. Orkney, Inc. [on­line], 2008. [cit. 2008­ 11­12]. Dostupný z WWW: Orkney, Inc. Dokumentace pgRouting. Orkney, Inc. [on­line], 2009. [cit. 2009­04­06]. Dostupný z WWW: Problém obchodního cestujícího in Wikipedie [on­line], 2009 [cit. 2009­03­03]. Dostupný z WWW: Ředitelství silnic a dálnic, Silniční databanka Ostrava. Využití informační základny. [on­line], 2009. [cit. 2009­03­10]. Dostupný z WWW: SCHNEIDER, Adam. GPS Visualizer. [on­line], 2009. [cit. 2009­04­13]. Dostupný z WWW: Souřadnicový systém in Wikipedie [on­line], 2009 [cit. 2009­04­15]. Dostupný z WWW: TopoGrafix. GPX 1.1 Schema Documentation. TopoGrafix [on­line], 2004. [cit. 2009­03­02]. Dostupný z WWW: VOŘÍŠEK, Pavel. S­JTSK ­­ Systém jednotné trigonometrické sítě katastrální., Vysoké Mýto: VOŠ a SŠS Vysoké Mýto, 2008. World Geodetic System in Wikipedie [on­line], 2009 [cit. 2009­04­01]. Dostupný z WWW: ZÁMIŠ, Jaroslav. Datový model pro data z ČSÚ., Plzeň: Západočeská univerzita, 2007. PŘÍLOHY 57

Přílohy

Trasa z Hradce Králové do Čeperky

2009-01-01T12:00:00Z Hradec Králové obec 3 2009-01-01T13:00:00Z Vysoká nad Labem obec 3 2009-01-01T14:00:00Z Čeperka obec 3 Z Hradce Králové do Čeperky 2009-01-01T12:00:00Z obec 3 2009-01-01T13:00:00Z obec 3 2009-01-01T14:00:00Z obec 3 PŘÍLOHY 58

startpoint Cesta z Odrovic 284792 do Kupařovic

485960 Brno-venkov xsi: schemaLocation="http:// Jihomoravský www.topografix.com/GPX/1/1 gpx.xsd" 186 xmlns="http://www.topografix.com/GPX/1/1" xmlns: xsi="http://www.w3.org/2001/XMLSchema -instance"> Odrovice to Kuparovice lat="49.0438051049085"> A road network route 2009-04-26T14:09:55.00 Kupařovice Mroute Route endpoint 2d 1 Mroute: Main site text/html endpoint 281916 485924 2009 Brno-venkov Creative Commons BY Jihomoravský 282 Route calculation Odrovice to Kuparovice text/xml A road network route Mroute 2009-04-26T14:09:55.00 1.0 Route calculation text/xml getRoute ok 1 Routing done. Calculated route 2921 167.720885 fast 2009-04-26T14:09:55.00 1 Odrovice Route startpoint 2d 1 lon="16.5011232596409"> 2009-04-26T14:09:55.00 PŘÍLOHY 59

Malešovice 590 2d 38.61845 1 284792 2 284792 485938 Brno-venkov lon="16.4920090450511"> Jihomoravský 2009-04-26T14:09:55.00 3 Kupařovice 395 2d 1916 1 106.11766 281916 0 281916 485924 Brno-venkov Jihomoravský lon="16.4880239029545"> 0 2009-04-26T14:09:55.00 0 Kupařovice 0 2d 0 1 0 281997 3 281997 485924 Brno-venkov Jihomoravský 3 395 415 22.984775 1 2009-04-26T14:09:55.00 Kupařovice 2d 1 281916 281916 485924 Brno-venkov Jihomoravský 4 39524 PŘÍLOHY

Schéma databáze 60 Ilustrace 2: Schéma databáze aplikace PŘÍLOHY 61

Příklad použití klienta mroute@ugly ~/mroute $./mroute-client -u http://localhost/cgi-bin/mroute -f Brno -t Praha -e Route (fast, toll): Brno to Praha

1. from Brno, Brno-město, Jihomoravský take road I/42, drive 1.393 km 2. from Brno, Brno-město, Jihomoravský take road I/52, drive 1.262 km 3. from Brno, Brno-město, Jihomoravský take road II/0, drive 0.325 km 4. from Brno, Brno-město, Jihomoravský take road II/602, drive 0.971 km 6. from Ostopovice, Brno-venkov, Jihomoravský take road I/23, drive 0.802 km 7. from Ostopovice, Brno-venkov, Jihomoravský take highway 1, drive 1.505 km 8. from Troubsko, Brno-venkov, Jihomoravský take highway 1, drive 5.456 km 9. from Omice, Brno-venkov, Jihomoravský take highway 1, drive 3.667 km 10. from Ostrovačice, Brno-venkov, Jihomoravský take highway 1, drive 10.18 km 11. from Lesní Hluboké, Brno-venkov, Jihomoravský take highway 1, drive 1.667 km 12. from Přibyslavice, Brno-venkov, Jihomoravský take highway 1, drive 3.93 km 13. from Velká Bíteš, Žďár nad Sázavou, Vysočina take highway 1, drive 8.622 km 14. from Ruda, Žďár nad Sázavou, Vysočina take highway 1, drive 6.45 km 15. from Velké Meziříčí, Žďár nad Sázavou, Vysočina take highway 1, drive 5.63 km 16. from Lavičky, Žďár nad Sázavou, Vysočina take highway 1, drive 6.656 km 17. from Měřín, Žďár nad Sázavou, Vysočina take highway 1, drive 6.63 km 18. from Nadějov, Jihlava, Vysočina take highway 1, drive 7.969 km 19. from Kozlov, Jihlava, Vysočina take highway 1, drive 6.283 km 20. from Střítež, Jihlava, Vysočina take highway 1, drive 6.765 km 21. from Smrčná, Jihlava, Vysočina take highway 1, drive 1.712 km 22. from Zbinohy, Jihlava, Vysočina take highway 1, drive 9.623 km 23. from Bystrá, Pelhřimov, Vysočina take highway 1, drive 3.047 km 24. from Vystrkov, Pelhřimov, Vysočina take highway 1, drive 8.923 km 25. from Koberovice, Pelhřimov, Vysočina take highway 1, drive 7.112 km 26. from Hořice, Pelhřimov, Vysočina take highway 1, drive 0.953 km 27. from Hořice, Pelhřimov, Vysočina take highway 1, drive 7.944 km 28. from Loket, Benešov, Středočeský take highway 1, drive 9.316 km 29. from Soutice, Benešov, Středočeský take highway 1, drive 7.062 km 30. from Psáře, Benešov, Středočeský take highway 1, drive 8.084 km 31. from Český Šternberk, Benešov, Středočeský take highway 1, drive 6.658 km 32. from Ostředek, Benešov, Středočeský take highway 1, drive 4.968 km 33. from Hvězdonice, Benešov, Středočeský take highway 1, drive 1.579 km 34. from Hvězdonice, Benešov, Středočeský take highway 1, drive 5.856 km 35. from Mirošovice, Praha-východ, Středočeský take highway 1, drive 5.145 km 36. from Kunice, Praha-východ, Středočeský take highway 1, drive 4.395 km 37. from Popovičky, Praha-východ, Středočeský take highway 1, drive 4.545 km 38. from Průhonice, Praha-západ, Středočeský take highway 1, drive 0.965 km 39. from Průhonice, Praha-západ, Středočeský take highway 1, drive 3.178 km 40. from Průhonice, Praha-západ, Středočeský take highway 1, drive 1.914 km 41. from Vestec, Praha-západ, Středočeský take road I/8, drive 0.219 km 42. from Vestec, Praha-západ, Středočeský take road I/8, drive 0.788 km 43. from Praha, Hlavní město Praha, Hlavní město Praha take road I/29, drive 0.718 km 44. from Praha, Hlavní město Praha, Hlavní město Praha take road I/29, drive 1.247 km 45. from Praha, Hlavní město Praha, Hlavní město Praha take road I/29, drive 1.793 km 46. from Praha, Hlavní město Praha, Hlavní město Praha take road I/29, drive 0.289 km 47. from Praha, Hlavní město Praha, Hlavní město Praha take road II/600, drive 0.429 km 48. from Praha, Hlavní město Praha, Hlavní město Praha take road II/0, drive 5.187 km 49. from Ořech, Praha-západ, Středočeský take road I/1, drive 3.107 km 50. from Ořech, Praha-západ, Středočeský take road I/1, drive 2.94 km PŘÍLOHY 62

51. from Chrášťany, Praha-západ, Středočeský take road I/1, drive 0.521 km 52. from Chrášťany, Praha-západ, Středočeský take road I/1, drive 2.193 km 53. from Hostivice, Praha-západ, Středočeský take road I/6, drive 2.223 km 54. from Hostivice, Praha-západ, Středočeský take road I/6, drive 1.406 km 55. from Praha, Hlavní město Praha, Hlavní město Praha take road I/6, drive 3.875 km 56. from Praha, Hlavní město Praha, Hlavní město Praha take road I/6, drive 0.309 km 57. from Praha, Hlavní město Praha, Hlavní město Praha take road I/6, drive 0.834 km 58. from Praha, Hlavní město Praha, Hlavní město Praha take road I/6, drive 1.535 km 59. you reach Praha, Hlavní město Praha, Hlavní město Praha

Route end. Total 219.978 km. Estimated time: 2:08:40. PŘÍLOHY

Zobrazení cesty z Brna do Prahy vypočtené vytvořenou aplikací

Ilustrace 3: Zobrazení cesty z Brna do Prahy vypočtené vytvořenou aplikací (Zdroj mapy:

Google Maps, http://maps.google.com, vykresleno aplikací GPS Visualizer) 63 PŘÍLOHY Zobrazení cesty z Brna do Prahy vypočtené Google Maps

Ilustrace 4: Zobrazení cesty z Brna do Prahy vypočtené Google Maps (Zdroj mapy: Google Maps, http://maps.google.com) 64