Převodník geografických dat

Transkript

1 Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta Převodník geografických dat Aplikace vývojových technik semestrální práce Jan Grmela, 2. ročník, Ekonomická informatika Brno,

2 Obsah 1 Úvod Cíl práce Postup řešení Vstupní data Data Silniční databanky Ostrava Tabulka VUZLY.dbf Formát CIS_UZLU Formát ICZUJ Formát CHAR_UZLU Tabulka VUSEKY.dbf Formát CIS_USEKU Formát SILNICE Tabulka CDMAB.dbf Výstupní data Tabulka adm_units Tabulka edges Tabulka node_types Tabulka nodes Tabulka edges_systems Tabulka places Tabulka roads Tabulka systems Algoritmus převodu Diskuse Závěr Seznam použité literatury

3 1 Úvod Grafové algoritmy (v našem případě aplikované na geografické mapy) prošly od doby svého vzniku, kterou je obvykle uváděna doba vzniku problému sedmi mostů v Královci (Prusko, dnes Rusko), dlouhou cestou. Otázka tehdy byla položena následovně: Je možné přejít všechny mosty tak, abychom na každý vstoupili jen jednou? Problém vyřešil v roce 1736 Leonhard Euler s tím, že to možné není. Podle něj byl pojmenován speciální případ grafu eulerovský. Je to takový graf, který lze nakreslit jedním tahem. Dalším významným momentem historie grafových algoritmů je vytvoření algoritmu pro nalezení minimální kostry grafu. Tento algoritmus byl vytvořen 1926 a následně použit pro výstavbu elektrické sítě na Moravě. Od té doby se teorie grafů stala významnou matematickou disciplínou, na které závisí mnohé vymoženosti dnešní doby. Silniční sítě, zásobování energiemi, či například to, zda se dostanete včas na dovolenou. Jednou z podskupin teorie grafů je i hledání nejkratších či nejvýhodnějších cest. Tato práce má připravit půdu pro další možné aplikace tímto problémem se zabývající. 2 Cíl práce Cílem práce Převodník geografických dat je realizace aplikace, která umožní import dat o silniční síti České republiky do databáze jiného formátu. Vstupní data pocházejí od Ředitelství silnic a dálnic ČR a jsou volně dostupná ve formátu dbase III [1] na jejich webových stránkách. Jako výstupní databáze byla zvolena oblíbená PostgreSQL kvůli jejímu vysokému výkonu, dobré přenositelnosti a snadnému použití. Vzniklá databáze může později sloužit jako datový sklad pro účely aplikace implementující některé grafové algoritmy. 3 Postup řešení 3.1 Vstupní data Největším problémem, který bylo nutno před započetím práce na samotném programu vyřešit, bylo získání vstupních dat. Geografická data, a to jak rastrová, vektorová či textová (popisná) jsou významným obchodním artiklem a není snadné je získat. Téměř všechny organizace, které s takovým daty pracují, jsou ochotny je poskytnout výhradně pro osobní použití (nikoli tedy pro automatizované zpracování), mnohdy za úplatu. Velké množství dat je taktéž v nepoužitelných vstupních formátech (zejména rastrových), jde například o oblíbené mapové servery Seznamu či Googlu. Zde se taktéž vyskytuje licenční problém - 3 -

4 zakazující automatizované použití zmíněných serverů. Ani v případě státní správy není situace o mnoho lepší. Server portálu Ministerstva vnitra a Ministerstva životního prostředí, který poskytuje data na adrese disponuje sice množstvím vhodných dat, bohužel ale jen v rastrovém formátu. Snad jediným volně dostupným zdrojem (pokud pomineme projekt OpenStreetMap na adrese jenž je ale zaměřen spíše na koncového uživatele), který zároveň zveřejňuje data v dobře dokumentovaném a snadno čitelném formátu je Ředitelství silnic a dálnic České republiky, konkrétně Silniční databanka Ostrava. Na jejich webových stránkách ( je k dispozici sada souborů popisující silniční síť České republiky. Sada je aktualizována dvakrát ročně. 3.2 Data Silniční databanky Ostrava Data, která lze stáhnout ze stránek ŘSD, jsou ve standardizovaném formátu ERSI Shapefile (specifikace viz [2]), který popisuje nejen grafickou strukturu formou vektorového zobrazení, ale také zobrazená místa formou textových nebo číselných údajů. Po důkladné analýze za pomocí nástrojů dodaných firmou ERSI (zejména ArcExplorer) a prostředky operačního systému, bylo zjišťeno, že právě soubor, obsahující data popisná (nikoli grafická), by mohl být klíčem k vyřešení problému nedostupnosti dat. Jde totiž o sadu tabulek v dobře podporovaném formátu dbase III. Bohužel, k těmto datům takřka neexistuje dokumentace (mimo několika řádků na webu). Zodpovědné osoby ŘSD na ové dotazy ohledně dokumentace nereagovaly a tak bylo nutno značný čas věnovat analýze dat kvůli zjištění významu jednotlivých sloupců v tabulkách. Po důkladném prohledání webu se podařilo získat dokument analyzující zátěž životního prostředí zpracovaný Ministerstvem dopravy ČR [3]. V dokumentu byly použity dotazy právě na databázi Silniční databanky, což přineslo mnoho užitečných informací. Ze souborů, které jsou na webu k dispozici byly nakonec použity tyto tři: VUSEKY.dbf tabulka úseku (silnic) propojujících jednotlivé uzly VUZLY.dbf tabulka uzlů (křižovatek) CDMAB.dbf tabulka administrativních jednotek Ilustrace 1: Náhled tabulky VUZLY.dbf - 4 -

5 Bohužel, tak, jak je databáze navržena, je dost obtížně použitelná. Tedy alespoň, chceme-li dosáhnout přijatelné rychlosti při práci s ní. Databáze porušuje mnoho doporučení pro tvorbu relačních databází. Kupříkladu nevhodné použití textového primárního klíče či téměř žádná normalizace tabulek. Příkladem může být ilustrace výše, kdy je jasně vidět zbytečná redundance v podobě textového popisu druhu křižovatky. Z výše uvedených důvodů a také kvůli omezeným možnostem, které dbase III nabízí, bylo rozhodnuto, že musí být tato data převedena do jiného formátu, kde budou silněji aplikována doporučení pro tvorbu relačních databází a bude taktéž provedena normalizace a lepší návrh tabulek Tabulka VUZLY.dbf Tabulka obsahuje seznam uzlů, tedy obvykle křižovatek. Některé body jsou ale například začátkem či koncem komunikace či hraničním přechodem. Popisuje název umístění (pokud nějaký existuje) a identifikační číslo územní jednotky (nekompatibilní s ČSÚ). Zjištěný význam dat popisuje následující tabulka: CIS_UZLU číslo uzlu ADM[1-2] čísla administrativních jednotek, ve kterých se uzel nachází (CDMAB) ICZUJ identifikační číslo základní územní jednotky ICZUJ_TEXT název územní jednotky SOU_X souřadnice v ose X nevyužito SOU_Y souřadnice v ose Y nevyužito VYS_SOU_Z souřadnice v ose Z nevyužito CHAR_UZLU typ uzlu (k řižovatk a, hraniční přechod, ) CHAR_TEXT název typu uzlu POCKR_DUZ význam není znám POCV_DUZ význam není znám KR_UZEL[1-8] do kterého úseku křižovatky úsek vchází/vychází ORIENT[1-8] Orientace -- + vstupuje do uzlu, - vystupuje z uzlu NAV_UZEL[1-8] CIS_UZLU spojeného s tímto uzlem DAT_ZAZNAM datum vytvoření záznamu Tabulka 1: Struktura tabulky VUZLY.dbf Formát CIS_UZLU CIS_UZLU je primárním klíčem VUZLY.dbf. Jde tedy o unikátní označení konkrétního uzlu. Formát je popsán regulárním výrazem ^([0-9]{4}[ABC]{1}[0-9]{3})([0-9]{2})$. První ozávorkovaná část uvozuje číslo uzlu, druhá (volitelná) v případě křižovatek udává, o jaký úsek křižovatky jde. Z výše uvedeného plyne, že může existovat několik uzlů se stejnou první částí lišících se jen v čísle úseku křižovatky. Takovou křižovatku nazýváme komplexní. Obvykle jde o stavby, jakými jsou dálniční mosty s přivaděči nebo křižovatky, kde se cesty nekříží v jednom místě, jsou ale propojeny pomocnými komunikacemi (kruhový objezd)

6 Tabulka VUZLY.dbf neobsahuje údaje k dílčím uzlům komplexních křižovatek, jen ke křižovatkám samotným Formát ICZUJ Původní domněnka byla taková, že tento kód bude souhlasit s údaji poskytovanými Českým statistickým úřadem ( Ta se bohužel ukázala jako nepravdivá, jelikož kódy IČZÚJ s ČSÚ vůbec nesouhlasí. Bylo tedy nutno využít i sloupec ICZUJ_TEXT pro vytvoření vlastního seznamu územních jednotek Formát CHAR_UZLU Písmeno či číslo uvedené v CHAR_UZLU (a duplicitně textově zapsané v CHAR_TEXT) udává, o jaký druh uzlu se jedná. Druhy mohou být následující: 1 začátek nebo konec komunikace 2 začátek nebo konec přívozu 3 začátek nebo konec nevybudované ulice 4 začátek nebo konec vojenského prostoru 5 státní hranice 6 začátek nebo konec směrového rozdělení 7 bod jednoznačnosti 8 změna počtu dopravních pruhů (slovo pruhů je odhad) 9 jiný bod M křižovatka mimoúrovňová N křižovatka mimoúrovňová (jiný typ, není určeno) R křižovatka úrovňová světelná (slovo světelná je odhad) U křižovatka úrovňová Tabulka VUSEKY.dbf Tato tabulka popisuje propojení jednotlivých uzlů (křižovatek) mezi sebou. Nese důležité informace týkající se například délky úseku, názvu silničního tahu, ke kterému úsek přísluší či čísla silnice. Významy jednotlivých sloupců (které se podařilo zjistit) shrnuje následující tabulka

7 CIS_USEKU číslo úsek u -- <do uzlu> <z uzlu> DAT_ZAZNAM datum vytvoření záznamu ADMINJ k ód administrativní jednotk y (seznam jednotek v CDMAB) DELKA_US délk a úsek u v metrech DOPR_SMERY dopravní směry 0 obousměrný úsek, 1 jednosměrný PAPR_VETEV zda jde o paprsek či větev k řižovatk y (hodnoty: PAPRS, VETEV) KOD_TR_KOM k ód třídy k omunik ace 1 dálnice, 2-4 silnice třídy SILNICE číslo silnice VYBR_SIT prázdné VYM_TAHY není známo. Hodnoty U, R, P, O, K, I, F, prázdná PEAZ_KOM[1-8] ETAH[1-4] číslo peážující (souběžné) komunikace číslo evropsk ého silničního tahu PORADI_US pořadí úseku v celé silnici Tabulka 2: Struktura tabulky VUSEKY.dbf Formát CIS_USEKU CIS_USEKU je zadáno formou dvou CIS_UZLU v jedné buňce. Formát tohoto pole popisuje regulární výraz ^[0-9]{4}[ABC]{1}[0-9]{3}[0-9\ ]{2}[0-9]{4}[ABC]{1}[0-9]{3}[0-9\ ]{0,2}$. Z tohoto regulárního výrazu je zřejmé, že formát sloupce je naprosto nevhodný pro jakoukoli manipulaci prostřednictvím databázového stroje. V dnešní době sice již existují i SŘBD, které dokáží vyhledávat data v tabulkách pomocí regulárního výrazu, je ale velmi pravděpodobné, že půjde o operaci značně časově náročnou a proto je lepší se použití tohoto kódu jako primárního klíče vyhnout Formát SILNICE Pole silnice udává číslo silnice. Toto pole má následující tvar: 1 až 71 I. třída 101 až 648 II. třída 0031 až libovolné pětimístné číslo III. třída formát <číslo> <písmeno> nebyl zjištěn význam, může obsahovat číslo dálnice Tabulka CDMAB.dbf Tabulka obsahuje pouze dva využité sloupce KOD a VYZNAM. Dále obsahuje sloupec ZKR, ten ale není na žádném řádku použit. KOD udává číslo administrativní jednotky a VYZNAM její název. Aby byla tabulka kompletní a mohli jsme se na ni odkazovat z relačně spojených tabulek, je třeba doplnit do ní ještě čtyři položky kódy okolních států: SRN, SR, RAKOUS a POLSKO. Z jejich kódu je význam zřejmý. Jejich neuvedení v původní tabulce je porušením relačních vztahů databáze

8 3.3 Výstupní data Jak již bylo zmíněno, původní databáze ve formátu dbase III zcela nevyhovuje požadavkům na výkon a formát dat. Byla proto navržena nová databáze na platformě PostgreSQL. Databáze obsahuje tyto tabulky: Ilustrace 2: Struktura databáze adm_units seznam administrativních jednotek edges úseky (silnice) node_types druhy uzlů (křižovatek) nodes uzly edges_systems propojovací tabulka systems s edges (vztah M:N) places seznam pojmenovaných míst roads seznam silnic systems seznam silničních tahů Ve většině tabulek byl vytvořen více než jeden index (nad primárním klíčem) nad textovými daty (jako je například původní číslo úseku či uzlu). Důvodem je značné zvýšení rychlosti při konverzi původní databáze na novou. Textová data totiž provizorně slouží jako primární klíč (spojení s původní databází) a provádí se podle nich výběr. Tyto indexy mohou být později zrušeny, nebude-li aplikace, která bude s databází pracovat, vyžadovat data v původním formátu

9 Databáze v současné podobě nepodporuje uložení komplexních křižovatek, ty jsou redukovány na jediný uzel. Taktéž nejsou do databáze uložena data s dosud neznámým významem, případně jsou uložena jen data, která lze zpracovat (jako v případě tabulky roads, kde nejsou dokonale zpracovávány informace ze vstupního sloupce VUSEKY.SILNICE) Tabulka adm_units Tabulka obsahuje údaje o administrativních jednotkách. code kód administrativní jednotky dle původní databáze ŘSD Tabulka edges Údaje o úsecích silniční sítě silnicích. from_node výstupní uzel to_node vstupní uzel lenght délka úseku v metrech road informace o silnici příslušící k úseku, odkaz do tabulky roads->id bidirectional TRUE v případě, že jde o obousměrný úsek canonical_name původní jméno úseku dle ŘSD Tabulka node_types Druhy uzlů (křižovatek). code kód druhu uzlu dle ŘSD name název druhu uzlu Tabulka nodes Uzly silniční sítě křižovatky. Id primární klíč adm_unit1 první administrativní jednotka (odkaz do adm_units->id) adm_unit2 druhá administrativní jednotka (odkaz do adm_units->id) place název místa, kde se uzel nachází (odkaz do places->id) node_type druh uzlu (odkaz do node_types->id) canonical_name původní název uzlu dle ŘSD Tabulka edges_systems Propojovací tabulka mezi tabulkami edges a systems

10 edge_id odkaz do edges->id system_id odkaz do systems->id Tabulka places Pojmenovaná geografická místa (např. silnice prochází městem a zde se uloží jeho název). name název místa code IČZÚJ dle ŘSD (nekompatibilní s ČSÚ) Tabulka roads Silnice navázané k úsekům. code kód silnice dle ŘSD class třída silnice 1 dálnice, 2-4 silnice I. až III. třídy number číslo silnice Tabulka systems Evropské silniční a dálniční tahy (např. E461, E50, ). name název tahu bez E, tj. jen 461, 50, 3.4 Algoritmus převodu Celý algoritmus je snadno možno vyčíst z přiloženého zdrojového kódu, v následujících odstavcích bude popsán zjednodušenou formou, která však postačí pro vytvoření základní představy o procesu převodu. Algoritmus byl realizován v programovacím jazyce Perl [3] kvůli jeho snadno čitelné syntaxi, dobré přenositelnosti a snadném rozšiřování pomocí přídavných programových modulů. Při návrhu struktury databáze a algoritmu převodu byly využity některé poznatky z diplomové práce Jana Koláře [4]. Na začátku běhu aplikace je nezbytná kontrola spojení s databází PostgreSQL a ověření existence vstupních souborů. Poté již může začít samotný převod. Program informuje o průběhu své práce vypisováním informací na standardní výstup. Jeho práce se dělí 8 relativně samostatných částí. Tyto není nutné provádět atomicky, je to však doporučeno kvůli zachování dokonalé integrity dat. Každý krok ovšem už atomický být musí. Dojde-li k neočekávanému přerušení běhu programu uprostřed některého z kroků, je nezbytně nutné databázi (nebo alespoň tabulku, na které se pracovalo) před pokračováním vyprázdnit. Při standardním běhu program automaticky pokračuje krok

11 po kroku až do okamžiku, kdy je celá databáze převedena. Celý program realizuje následující kroky: 1. Převod uzlů (křižovatek) Vyčtení veškerých uzlů z tabulky VUZLY.dbf a jejich prosté uložení (včetně originálního názvu). Prozatím není povolena možnost tvorby komplexních křižovatek. 2. Převod úseků (silnic) Tento krok je již značně komplikovanější, je třeba dle originálního čísla úseku najít v nové tabulce uzlů odpovídající uzly a tyto dva prostřednictvím úseku spojit. Taktéž je úsek doplněn o směrovost. V případě jednosměrnosti je nastaveno správné pořadí dat ve sloupcích from_node a to_node. 3. Vytvoření administrativních jednotek Přenese se původní seznam z tabulky CDMAB.dbf, změní se jeho kódování na UTF-8 a připojí se k němu také kódy zemí, se kterými ČR sousedí. 4. Propojení administrativních jednotek s uzly Znovu se projde původní tabulka uzlů a provede se propojení dle canonical_name v nové tabulce nodes. 5. Vytvoření tabulky míst a propojení s uzly Opět se prochází původní tabulka uzlů a přiřazují se k jednotlivým položkám místa z tabulky places. Není-li místo nalezeno, vytvoří se. 6. Propojení druhů křižovatek s uzly Je naplněna tabulka node_types druhy křižovatek a je spojena s tabulkou nodes. 7. Propojení názvů silnic s úseky Projde se tabulka úseků. Jednotlivým položkám je nastavováno příslušné umístění. V případě, že umístění v tabulce places dosud neexistuje, je vytvořeno. 8. Propojení silničních tahů s úseky Stejný postup jako v předchozím kroku, jen je aplikován na silniční tahy. Dokončení převodu program oznámí na standardní výstup. V té chvíli máme k dispozici novou databázi naplněnou aktuálními daty. 4 Diskuse Celý algoritmus byl navržen s ohledem na jednoduchost. Je zřejmé, že některé kroky by mohly být prováděny současně (např. vytvoření uzlu a současně přiřazení administrativní jednotky k uzlu). Tento přístup by však následně znesnadnil správu kódu a zbytečně zvýšil jeho složitost na úkor čitelnosti a snadné pochopitelnosti. Jak již bylo na několika místech zmíněno, algoritmus prozatím nedokáže vytvářet komplexní křižovatky. Každou takovou nahradí jednoduchým uzlem. Tento postup vnáší do databáze ne

12 přesnosti jelikož neznáme délku trasy z jedné části křižovatky do druhé, což se může u některých tras projevit podhodnocením celkové délky trasy. Tento nedostatek je poměrně snadno řešitelný a bude zřejmě opraven v některé z novějších verzí programu. Dalšími možnými vylepšeními je například odhad časové náročnosti převodu na konkrétním počítači, analýza obsahu databáze před začátkem převodu či možnost spuštění jen některých kroků programu. 5 Závěr Realizace tohoto programu nám dala možnost vystavět na jím vygenerované databázi aplikace, týkající se grafových algoritmů hledání nejkratší cesty, různé analýzy silniční sítě a podobně. Největším problémem nebyla samotná realizace, tj. naprogramování převodních algoritmů, nýbrž analýza vstupních dat. Pokud by v době návrhu existoval dostatek dokumentace, byla by i doba realizace mnohem kratší a je pravděpodobné, že by výsledek obsahoval mnohem více dat příslušících jak k uzlům, tak k úsekům silniční sítě. Program byl vyvíjen na 64-bitovém linuxovém počítači s následující konfigurací: Intel Celeron 220 1,2 GHz, 1 GiB DDR2/533 RAM, CentOS 5.1 x86_64, Perl 5.8.8, PostgreSQL Testovací běh programu s lokálně připojenou databází zabral necelých 31 minut. Výstupní databáze má (vzhledem k použití indexů na textové sloupce) 43 MiB. Tabulka edges asi 31 tisíc a tabulka nodes asi 22 tisíc záznamů. Zdrojový kód programu rsd2mroute je volně k dispozici na adrese pod licencí GNU GPL 3 nebo novější. Vstupní data jsou k dispozici na stránkách Silniční databanky [5]

13 6 Seznam použité literatury [1] Více autorů. Wikipedia: dbase < Wikimedia, 2008 [2] Environmental Systems Research Institute. ESRI Shapefile Technical Description. ERSI, [3] DOSTÁL, Ivo. Hodnocení stávající dopravní infrastruktury a variant jejího plánovaného rozvoje z hlediska záboru půdy a vlivů na morfologii a fragmentaci krajiny. Centrum dopravního výzkumu, Ministerstvo dopravy ČR, 2004 [3] DAŘENA, František. Myslíme v jazyku Perl. Grada, ISBN [4] KOLÁŘ, Jan. Implementace algoritmů prohledávání dopravní sítě v prostředí PostgreSQL diplomová práce. VŠB TU Ostrava, [5] Více autorů. Využití informační základy Silniční databanky Ostrava < Ředitelství silnic a dálnic ČR,