Diplomová práce Grafický editor schémat dopravních systém

Transkript

1 Západoeská univerzita v Plzni Fakulta aplikovaných vd Katedra informatiky a výpoetní techniky Diplomová práce Grafický editor schémat dopravních systém Plze, 2005 Jana Hájková

2 Podkování Ráda bych podkovala vedoucímu diplomové práce panu Doc. Ing. Pavlu Heroutovi, PhD. za odbornou pomoc a užitené rady pi zpracování mé diplomové práce. Nemenší dík patí také všem tm, kteí se mnou bhem mnoha msíc, ve kterých jsem diplomovou práci vytváela, mli tém bezmeznou trplivost, mé rodin i pátelm za jejich podporu a pochopení v prbhu celého mého studia.

3 Abstract Abstract Graphical Editor of the Traffic System Schemes This work describes the editor of street graphs, which is a part of system for a traffic simulation Java Urban Traffic Simulator (JUTS). It enables the users to create a street graph from the given geographical data. The street graph is a detailed road map of a town district, it includes roads, crossroads, vehicle or parking lanes. Street graphs are intended to be used as an environment for a traffic simulation in Pilsen (Czech Republic), or in any other town which can provide the whole simulation system with all input data in the correct format. All actions of the editor can be done in an elegant way, users do not need to be specialists in geographical systems. The users can create a new map in XML format.

4 Obsah Obsah 1 Úvod Systém JUTS Editor Formáty soubor Souadnice uzlových bod Souadnice segment silnic Popis kižovatek Grafická ást simulaní mapy Simulaní ást simulaní mapy GIS systémy Existující prostedky Funknost, výbr vhodných funkcí Návrh editoru Návrh grafického prostedí Algoritmy využívané editorem Vytvoení silniní sít Výbr uzlového bodu Výbr segmentu silnice Oprava chybného segmentu Vytvoení sít kižovatek Vygenerování hranice kižovatky Výpoet hranic jízdních pruh, jejich korekce Generování odboovacích jízdních pruh Automatické generování bunk v kižovatce Nalezení kižovatky Funkce editoru Funkce pro práci se souborem Pohledové funkce Funkce pro práci s elementy mapy Nástroje Nápovda Implementace editoru Grafické tídy GAboutDlg GColorDlg GChooseCrossroadDlg GNewMapDlg GPointMoveDlg GSaveMapDlg GScaleDlg GUserInterfaceDlg GWindow MyPanel...47

5 Obsah 5.2 Podstatné negrafické tídy CrossroadsDOM GraphicXML GDescription JUTS_constants Main MapXML Tídy pro elementy mapy AccessPlace CrossPoint GenTerm Krizovatka NextPlace Place PruhDovnitr PruhVen RamenoKrizovatky Road RoadSegment SuccPred VehicleLane Way Pomocné tídy Curve DoublePoint Line ObsluhaChyb Potíže pi ešení, možná zlepšení Závr...60 Literatura...61 Elektronické zdroje...61 Pílohy: A Uživatelská dokumentace

6 Prohlašuji, že jsem diplomovou práci vypracovala samostatn a výhradn s použitím citovaných pramen. V Plzni dne Jana Hájková

7 1 Úvod 1 Úvod Simulace dopravních systém jsou oblastí, která se prudce rozvíjí také díky zvyšující se výkonnosti výpoetní techniky. Nezastupitelné místo v píprav podklad a ve vizualizaci výsledk i píprav vstupních dat má i poítaová grafika. Simulaních systém existuje vtší množství na rzných úrovních detailnosti. V souasné dob msto Plze využívá pro simulaci dopravy v Plzni systém založený na makroskopické simulaci, který pracuje pouze s toky vozidel po jednotlivých komunikacích a vychází z koncentrace obyvatel v jednotlivých ástech msta. Systém umožující simulaci dopravy na mikroskopické úrovni (tzn. na úrovni jednotlivých vozidel) dosud nemá msto k dispozici. Z tohoto dvodu se rozvinula spolupráce ZU a msta Plzn na projektu JUTS (Java Urban Traffic Simulator), umožujícím zmínnou mikroskopickou simulaci. Projekt JUTS je komplexním projektem, na kterém v souasné dob pracuje tým lidí. Hlavní ást projektu je simulaní, ale krom ní je poteba nkolik dalších podprných aktivit, které se na vlastní simulací pímo nepodílejí. Jednou z nich je píprava simulaních map, tj. vstupních dat pro simulaci, podle kterých simulace na uritém konkrétním úseku probíhá. Mapy musejí být pipravovány na základ reálných geografických dat a dalších podklad, popisujících nap. dopravní znaení apod. Tchto dat existuje relativn znané množství, jak co do objemu, tak i do rznorodosti. V první verzi projektu JUTS byly tyto mapy pipraveny run. Tento zpsob má vícemén pouze nevýhody, mezi hlavní z nich patí: pípravu mže provádt pouze odborník detailn rozumjící zpsobu simulace v systému JUTS, jedná se o asov velmi náronou innost, výsledek je znan náchylný k chybám, které se špatn detekují a odstraují, jakékoliv zmny mapy jsou velmi obtížné. Z tchto dvod bylo rozhodnuto o vývoji grafického editoru, který by pípravu simulaních map maximáln ulehoval a odstranil všechny výše popsané problémy runí pípravy. Jeho ovládání musí být jednoduché a intuitivní, aby jej mohl používat i nezaškolený pracovník. Dále by editor ml vykazovat jistý stupe inteligence, tj. provést automatizovan všechny innosti, které provést lze. Úkolem grafického editoru naopak není jakkoliv vizualizovat výsledky simulace. Pomocí grafického editoru by mlo být možné pipravit simulaní mapu za dobu v ádu desítek minut, zatímco runí píprava je otázkou ádov dn. 1

8 2 Systém JUTS 2 Systém JUTS Stejn jako v jiných vtších mstech, není ani v Plzni ideální dopravní situace, nejen v úzkých ulikách historického centra, ale také na nkolikaproudových magistrálách i na bžných komunikacích. Systém pro dopravní simulaci mže být velmi užiteným nástrojem pi pedcházení dopravním zácpám, pi zjišování možných problém pi rekonstrukcích nebo pi zjišování, jak by se v dané oblasti zmnila dopravní situace, kdyby byla postavena, nebo naopak zrušena paralelní komunikace. Pouhou zmnou nastavených hodnot lze mnit parametry dopravní situace a silniního provozu. Uživatel mže snadno získat pouze statistiky ze simulované oblasti (tzv. offline simulace) nebo celou simulaci detailn sledovat (online simulace). Úsek koncepce a dopravního inženýrství Správy veejného statku msta Plzn [URL2] využívá pro simulaci dopravy v Plzni systém založený na makroskopické simulaci. Pro získání hodnot hustoty dopravy vychází ze zalidnní jednotlivých ástí msta a z umístní obchodních center a jiných oblastí se zvýšeným pohybem obyvatel. Protože dosud neexistuje žádný systém simulace dopravy na mikroskopické úrovni (tzn. na úrovni simulace jednotlivých vozidel), který by mlo msto k dispozici, rozvinula se spolupráce na projektu JUTS (Java Urban Traffic Simulator). Díky této spolupráci jsou k dispozici data potebná pro kompletní simulaci malé ásti msta Plzn, jedná se o silniní okruh v plzeské mstské ásti Lochotín, zahrnující pt svtelných kižovatek. Na zaátku vytváení JUTS projektu byl vytvoen návrh celého simulátoru a jeho mikroskopického modelu. Celý návrh je podrobn popsán v [Hart1]. V prbhu postupného vytváení simulátoru a následné rozšiující se spolupráce s mstem se celý projekt zaal rozrstat, vznikla ada subproblém, systém bylo nutné rozdlit na nkolik ástí a na celém projektu se zaal podílet nkolikalenný tým. V souasné dob se tedy systém skládá z nkolika základních ástí zobrazených na obrázku 2.1. Obr. 2.1: Struktura systému JUTS. Hlavní ást celého simulátoru tvoí simulaní jádro [Hart2], které nate mapy spolu se všemi potebnými daty udávajícími intenzitu provozu a zajišuje samotnou simulaci dopravy. Na simulaní jádro je navázáno grafické uživatelské rozhraní umožující ovládání simulace a její vizualizaci. Jak již bylo zmínno, do simulátoru je nutné dodat 2

9 2 Systém JUTS potebná vstupní data. Jedná se pedevším o mapy, které vytváejí prostedí pro simulovanou oblast, a o data udávající intenzitu provozu. Vstupní data je nutné simulátoru dodat v odpovídající podob (XML formát), je tedy nutné jejich pedzpracování. To je provádno v ástech systému oddlených od samotného simulátoru. Hodnoty intenzity silniního provozu jsou meny pomocí detektor (micích smyek), které jsou umístny v jednotlivých jízdních pruzích každé svtelné kižovatky. Detektory zaznamenávají poet vozidel, která jízdním pruhem projedou, a tyto poty jsou mimo jiné agregovány do patnáctiminutových interval a ukládány do centrálního poítae dopravní ústedny. Data tedy obsahují hodnoty namené jednotlivými detektory v konkrétních asových úsecích a poskytují tak systému pomrn pesnou informaci o potech vozidel projíždjících v danou dobu uritým územím. V souasné dob má systém k dispozici údaje za celý kalendání rok Zpracováním tchto údaj se zabývá jiná práce. Stejn jako data s hodnotami udávajícími intenzitu provozu je nutné pedzpracovat i poskytnutá geografická data a vytvoit z nich mapy oblasti, ve které má simulace probíhat. Tyto mapy je možné vytvoit run pímou editací XML soubor. Protože struktura mapy je ale pomrn složitá, vyžaduje její neautomatizované vytváení velké množství práce a asu. Proto je v systému, jako další z jeho ástí, vytváen grafický editor umožující pohodlnou a pomrn asov nenáronou poloautomatickou pípravu mapy pro simulaní systém. Celý proces simulace mže být provádn online, tzn. simulace je vizualizována bhem celého svého prbhu, nebo offline, kdy je simulace spuštna bez vizualizace a poté lze pracovat se získanými výslednými statistikami a údaji. Podrobnjší popis celého systému JUTS je možné najít také v [Hart3]. 2.1 Editor Úkolem editoru je pevádt natené geografické souadnice bod udávajících možné pozice kižovatek (tzv. uzlových bod) a souadnice oblastí, ve kterých jsou umístny silnice, pop. jejich ásti (tzv. segmenty silnic), do mapy reprezentované v podob XML souboru. Celý pevod je umožnn jednoduchým klikacím zpsobem, editor poloautomaticky generuje výslednou mapu a umožuje uživateli její základní úpravy. Pestože existence editoru k samotné simulaci není nezbytná, je tento zpsob grafické podpory simulace velmi dležitý. Pípravu mapy pro simulátor je možné realizovat run, ale její vytváení i pro nepíliš složité silniní sít je velmi nároné. Nejedná se pouze o pepoet souadnic jízdních pruh nebo hranic kižovatky, ale také o zajištní vzájemné návaznosti a logického propojení všech element mapy, vytvoení generátor a terminátor a dalších prvk pro zajištní generování vozidel do sít a jejich odebírání z ní a plynulé napojení všech ástí mapy. Vše musí být provedeno tak, aby byla pesn dodržena požadovaná struktura XML soubor grafické i simulaní ásti mapy. Editor pracuje s nkolika základními elementy mapy jako jsou silnice, jízdní pruh, kižovatka, buka v kižovatce, propojovací místo, generátor, terminátor. Významy jednotlivých element mapy budou vysvtlovány prbžn pi popisu návrhu a funknosti editoru. 3

10 2 Systém JUTS 2.2 Formáty soubor V celém projektu hrají velmi dležitou roli formáty vstupních a výstupních soubor. Vzhledem k tomu, že všechny souásti systému JUTS mezi sebou navzájem spolupracují, je výmna dat ve form soubor nezbytná. Jako základní formát dat pro výmnu byl zvolen v souasné dob pomrn rozšíený formát XML. Výhodnost jeho použití je i v kvalitní podpoe zpracování XML dokument programovými prostedky jazyka Java, ve kterém jsou jednotlivé ásti systému implementovány. Protože soubory slouží pro výmnu dat mezi navzájem oddlenými ástmi systému, bylo nutné urit jejich strukturu hned na zaátku píprav a návrh jednotlivých ástí. Zvolená struktura pak již zstala, krom nkolika drobných úprav, vícemén nezmnna. Vtšina soubor používaných v celém systému JUTS tedy využívá XML formát. Jinak je tomu však u soubor poskytovaných mstem. V tomto pípad se jedná o bžné textové soubory obsahující data získaná bu z databáze GIS nebo z micí ústedny. Grafický editor pracuje se dvma takovými soubory souborem se souadnicemi uzlových bod (2.2.1) a souborem se souadnicemi udávajícími ohraniující obdélníky pro jednotlivé segmenty silnic (2.2.2). Ostatní soubory, které editor naítá nebo generuje, jsou již v XML formátu. Jedná se o vstupní soubor s popisem kižovatek (2.2.3) a o dva výstupní soubory, které jsou editorem generovány grafickou ást mapy (2.2.4) a simulaní ást mapy (2.2.5) Souadnice uzlových bod Jedná se o vstupní soubor, který obsahuje souadnice jednotlivých uzlových bod. Uzlový bod je místo tvoící kižovatku, spojení dvou sousedních segment, nebo poátení, pop. koncový bod segmentu. Každý ádek souboru obsahuje data pro jeden uzlový bod mapy. Pro jednotlivé body jsou zadávány souadnice udávající znaku pro hranici, kterou jsou uzlové body v databázi GIS msta Plzn zobrazovány. Konená pozice uzlového bodu je tedy dána jako sted tverce zadaného souadnicemi v souboru (viz obr. 2.2) bod uprosted naznauje skutenou pozici uzlového bodu. Další hodnotou patící k jednotlivým uzlovým bodm je identifikátor. Jedná se o identifikátor používaný v rámci celé databáze msta. Grafický editor ani jiná souást systému JUTS s tmito hodnotami nepracuje. Obr. 2.2: Graficky znázornný význam jednotlivých souadnic pro jeden uzlový bod. Souadnice bod jsou zadávány v tzv. Kovákov souadném systému, neboli S-JTSK (Systém jednotné trigonometrické sít katastrální) [Vever], [URL1]. Jedná se o kartografické zobrazení používané na území eské republiky. V praxi to znamená, že 4

11 2 Systém JUTS ísla udávající jednotlivé souadnice jsou vztaženy k poátku této souadné soustavy, kterou je místo poblíž msta Talin. Píklad ásti souboru s nkolika definovanými uzlovými body je uveden na obrázku 2.3. Údaje jsou uvedeny v milimetrové pesnosti. xmin xmax ymin ymax id_kriz Obr. 2.3: Píklad ásti souboru s nkolika definovanými uzlovými body Souadnice segment silnic Jedná se o druhý textový soubor, který je do grafického editoru naítán. Soubor se souadnicemi segment silnic má podobnou strukturu jako pedchozí soubor, obsahující souadnice uzlových bod. Každá ádka obsahuje souadnice minimálního a maximálního bodu. Tyto body udávají ohraniující obdélník jednoho segmentu silnice. Konkrétní tvar segmentu uvnit ohraniujícího obdélníka není nijak definovaný, koncové body segmentu leží na hranici obdélníka. Na obrázku 2.4 a) je naznaen význam souadnic vzhledem k ohraniujícímu obdélníku, na obrázcích b) až d) je naznaeno, jak mohou vypadat segmenty popisované v jednotlivých ádcích. Pesný tvar segmentu není v žádné form obsažený ve vstupních datech. a) b) c) d) Obr. 2.4: a) Graficky znázornný význam jednotlivých souadnic pro jeden segment silnice; b) až d) možné tvary segment silnic. Jak je vidt na obrázku 2.5, každý ádek obsahuje adu dalších informací o jednotlivých úsecích. Jedná se pedevším o identifikátory sloužící k propojení segment s ostatními elementy v databázi msta. Tyto identifikátory jsou však pro úely systému JUTS nepoužitelné, protože nesplují potebná kritéria konkrétní popis viz kapitola 2.2.5, stejn jako ostatní položky popisující segmenty. Tyto hodnoty grafický editor ukládá (stejn jako identifikátory uzlových bod z pedchozího souboru), ale dále s nimi nepracuje, ani je nezahrnuje do výstupních popis mapy. XMIN XMAX YMIN YMAX L_PARAM RC ID_USEK CC_ULICE S III. t MK III. t MK III. t MK III. t Obr. 2.5: Píklad ásti souboru s nkolika definovanými segmenty silnic. Pro nedostatek místa byly oproti skutenému souboru použity zkratky S = silnice, MK = místní komunikace. 5

12 2 Systém JUTS Popis kižovatek Poslední vstupní soubor již narozdíl od pedchozích dvou využívá formát XML. Tento soubor obsahuje popis reálných plzeských kižovatek a je využíván v okamžiku mapování kižovatek na uzlové body silniní sít, kdy jsou uzlovým bodm pedstavujícím kižovatky piazovány konkrétní existující kižovatky. Aby bylo možné danou kižovatku jednoznan urit, musí mít každá svj jedinený identifikátor (jeho konkrétní umístní v popisu je uvedeno níže). Koenovým elementem uložených kižovatek je element <krizovatky> (viz obr. 2.9). Ten v sob obsahuje popisy jednotlivých kižovatek. Každá kižovatka <krizovatka> má dva atributy íslo <cislo> odpovídající íslování kižovatek v centrále dopravního úseku msta Plzn a popis <popiskrizovatky> udávající jména kížících se ulic, pop. ješt zažité jméno kižovatky. Uvnit každé kižovatky jsou popisovány její další vlastnosti a také její grafická struktura. Je zde umístn i identifikátor <idjutskrizovatky>, který kižovatku jednoznan uruje. Pipravená znaka <soucastoblasti> pro íslo <cislo> a popis oblasti <popisoblasti>, ve které je kižovatka umístna, zatím není využita, hodnoty tchto atribut budou do popisu kižovatek doplnny v budoucnu. Každá kižovatka je nadále urena svými rameny. Pro každé z nich je v popisu urený samostatný tag <ramenokrizovatky> s atributem <jmenoulice> obsahujícím jméno ulice, kterou popisované rameno kižovatky prochází. Na zaátku popisu každého ramena je zadána jeho orientace <orientace>. Ta mže obsahovat hodnotu od 1 do 12 v závislosti na natoení ramena kižovatky. Tato hodnota odpovídá umístní tchto íslic na hodinách (viz obr. 2.6). Samozejm, že takové zadávání orientace kižovatky je pomrn nepesné a pro uchovávání v XML souboru by bylo možné ukládat relativn pesnou hodnotu natoení segmentu. Zjišování pesného úhlu by ale, vzhledem k tomu, že jsou popisy kižovatek vytváeny run, pípravu soubor znan zpomalovalo a daná hodnota by i tak nemusela být zcela pesná. Hrubé (ale rychlé) zadání orientace pro tento úel pln postauje, pesné zjištní úhlu natoení ramena je ureno pozdji podle úhlu natoení segmentu silnice, ke kterému je rameno kižovatky piazeno. Následujícím tagem hned za orientací ramena kižovatky je umístn odkaz na nejbližší kižovatku <navazujicikrizovatka>, která je také popsaná. Obr. 2.6: Hodnoty pro hrubou orientaci popisu ramen kižovatky. Každé rameno obsahuje dv ásti pro každý smr jízdy jednu. Ty krom identifikátoru <idjutssilnice> obsahují popisy pro jednotlivé jízdní pruhy, které v silnici leží. Silnice ve smru vjezdu vozidel do kižovatky <vjezd> v sob zahrnuje 6

13 2 Systém JUTS popisy všech jízdních pruh <pruhdovnitr>, kterými vozidla vjíždí do kižovatky. Každý jízdní pruh má jako své atributy urené možné smry jízdy a to zkratkou <zkratka> (L = vlevo, R = rovn, P = vpravo, vetn všech libovolných kombinací), nebo plným popisem smru <popis>. Poslední atribut uruje poadí jízdního pruhu zleva ve smru jízdy <poradiodleva>. Pruh je pak popsán identifikátorem <idjutspruh>, íslem detektoru <cislodetektoru>, který je v daném pruhu umístn pod povrchem vozovky, a vzorcem pro výpoet intenzity prjezdu vozidel z detektor v kižovatce <namerenaintenzita>. Popis jízdních pruh v silnici ve smru z kižovatky <vyjezd> je oproti vjezdu výrazn jednodušší. Každý jízdní pruh <pruhven> obsahuje pouze atribut pro urení poadí jízdního pruhu zleva ve smru jízdy <poradiodleva>, tag pro identifikátor jízdního pruhu <idjutspruh> a vzorec pro výpoet intenzity prjezdu vozidel jízdním pruhem, uložený ve znace <vypoctenaintenzita>. Píklad základní struktury XML dokumentu je ve form stromu naznaený na obrázku 2.7. Jednotlivé znaky jsou zobrazeny v obdélnících, jejich atributy v pilehlých elipsách. Význam nkolika základních znaek a atribut vzhledem k reálné kižovatce je ukázán na obrázku 2.8. ást XML souboru pro zobrazenou vzorovou kižovatku je k dispozici na obrázku 2.9. Podrobn je zde popsáno to rameno kižovatky, které je v obrázku oznaeno do nejvtších podrobností. Obr. 2.7: Základní struktura XML, popsaná formou stromu. 7

14 2 Systém JUTS Obr. 2.8: Vztah jednotlivých znaek k reálné kižovatce. <krizovatky> <krizovatka cislo= k333 popiskrizovatky= Studentská Komenského > <idjutskrizovatky id= /> <soucastoblasti cislo= popisoblasti= /> <ramenokrizovatky jmenoulice= Studentská > <orientace>3</orientace> <navazujicikrizovatka id= /> <vjezd> <idjutssilnice id= /> <pruhdovnitr zkratka= L popis= vlevo poradiodleva= 1 > <idjutspruh id= /> <cislodetektoru cislo= 7 /> <namerenaintenzita>91</namerenaintenzita> </pruhdovnitr> <pruhdovnitr zkratka= R popis= rovn poradiodleva= 2 >... </pruhdovnitr> <pruhdovnitr zkratka= RP popis= rovn a vpravo poradiodleva= 3 >... </pruhdovnitr> </vjezd> <vyjezd> <idjutssilnice id= /> <pruhven poradiodleva= 1 > <idjutspruh id= /> <vypoctenaintenzita /> </pruhven> <pruhven poradiodleva= 2 >... </pruhven> </vyjezd> </ramenokrizovatky> <ramenokrizovatky jmenoulice= Kaznjovská >... </ramenokrizovatky> <ramenokrizovatky jmenoulice= Studentská >... </ramenokrizovatky> <ramenokrizovatky jmenoulice= Komenského >... </ramenokrizovatky> </krizovatka> <krizovatky> Obr. 2.9: Konkrétní píklad ásti XML souboru vztahující se ke kižovatce na obr

15 2 Systém JUTS Grafická ást simulaní mapy Tento soubor je prvním výstupním souborem editoru. Jedná se o grafickou ást vytvoené mapy. Soubor v sob ukládá souadnice, umístní a rozmry ohraniujících oblastí apod., data slouží pro vykreslení mapy v simulátoru. Je zde popsaný každý element, který se vykresluje, všechny popisované elementy mapy mají svj jednoznaný identifikátor, pomocí kterého jsou napojené na druhou simulaní ást (popsaná v kapitole 2.2.5). Struktura popisovaného XML souboru je znázornna na obrázcích 2.10 a) až f) ve form stromu, rozdleného na nkolik ástí. Pro rozdlení stromu jsem se rozhodla vzhledem k jeho velikosti a v závislosti na možnostech zobrazení. a) b) c) d) 9

16 2 Systém JUTS e) f) Obr. 2.10: Struktura XML ve form stromu: a) základní struktura; b) až f) podrobnjší struktura jednotlivých ástí. Koenovým elementem je element <graphics>. Ten naznauje, že se skuten jedná o grafickou ást mapy. Hlavní element v sob zahrnuje urení ohraniující oblasti celé mapy <BoundingBox> a ásti pro popis jednotlivých skupin element mapy jako jsou: silnice <RoadGraphic>, kižovatky <CrossRoadsGraphic>, generátory <GeneratorGraphic>, terminátory <TerminatorGraphic>. Ohraniující oblast celé mapy je urena obdélníkem <rect>. Ten je zadaný bodem udávajícím levý horní roh <point>, šíkou <width> a výškou <height>, které udávají rozmr obdélníka. Znaka <point> se v celém souboru používá velmi asto. Jedná se o zadání souadnic bodu. Její struktura je velmi jednoduchá, bod se skládá ze souadnice x <p_x>, souadnice y <p_y> a hodnoty udávající úrove ve vertikálním smru <p_h>. Tato hodnota je urena pro ešení problému mimoúrovového kížení apod. Nejastjší používanou hodnotou je 1, tzn. element se nachází na základní úrovni. Další asto používanou znanou je znaka popisující kivku <curve>. Strom znázorující její strukturu je vidt na obrázku Kivka je urena typem <type> udávajícím její vlastnosti. Možné hodnoty a jejich význam jsou: plná 0 perušovaná 1 dvojitá 2 dvojitá, zleva perušovaná 3 dvojitá, zprava perušovaná 4 Vlastnosti áry (zejména to, zda je možné ji pejíždt nebo ne) vyplývají z Pravidel silniního provozu. U každé kivky je znakou <shown> ureno, jestli má být pi vykreslování zobrazována, nebo ne (0 = ne, 1 = ano). Po definici typu a zobrazování jsou v definici kivky uloženy body <point>, které ji tvoí. Element kivky je využíván pro popis hranice kižovatek, silnic, jízdních pruh nebo pro urení oddlova jednotlivých jízdních pruh. Obr. 2.11: Struktura elementu popisujícího kivku. 10

17 2 Systém JUTS Jak již bylo zmínno, grafická ást mapy obsahuje popisy jednotlivých skupin element mapy. Jako první jsou v souboru uloženy popisy všech silnic. Každá silnice <RoadGraphicItem> je urena svým identifikátorem <roadid> a kivkou udávající hranici kižovatky <border>. Body jsou v kivce <curve> zadávány tak, jak je naznaeno na obrázku 2.12 a) v poadí A, B, C, D a E, parametr pro zobrazování je u hraniní kivky nastaven na 0 (nezobrazovat). Každá silnice se skládá z nkolika jízdních pruh <lane>. Jízdní pruh má svj identifikátor <laneid> a levý a pravý oddlova <divider>. Levý oddlova je vždy uveden jako první. Každý oddlova je tvoen jednou nebo více kivkami. Jestliže je celý oddlova tvoen kivkou jednoho typu, staí pro popis jediná kivka, pokud je nutné v prbhu oddlovae typ kivky mnit, je nutné k jeho urení nkolik kivek. Konkrétní píklad kivek v oddlovaích je uveden na obrázku 2.12 b). Levý oddlova se skládá ze dvou kivek, první je plná a obsahuje body A, B, druhá je perušovaná a tvoí ji body C a D. Pravý oddlova je tvoen jednou kivkou urenou body E, F, G a H. Pro urychlení vykreslování v simulátoru je již pímo v map ureno, které oddlovae je nutné vykreslovat a které ne. Pokud to tedy okolnosti nevyžadují, je parametr vykreslování kivek levého oddlovae <shown> nastaven vždy na 0 (tzn. nevykreslovat). Výjimka platí vždy pouze pro levý oddlova toho jízdního pruhu, který je nejvíce vlevo u jedné ze silnic ležících na stejném rameni kižovatky (to zajistí vykreslení dlicí áry mezi silnicemi). a) b) Obr. 2.12: Ukázka poadí vkládání bod do a) hranice silnice; b) kivek tvoících levý a pravý oddlova jízdního pruhu. V další ásti XML jsou popisovány kižovatky, které jsou v map obsažené. Každá kižovatka <CrossGraphicItem> je dána svým identifikátorem <crossid> a hranicí <border>. Hranice se skládá z nkolika kivek, ve kterých jsou body urující hranici ukládány tak, jak je naznaeno na obrázku 2.13 a). ísla oznaují poadí samotných kivek, kivka 3 obsahuje body v poadí A, B a je typu 1 (perušovaná), kivka 4 pak se skládá z bod B, C, D a je typu 0 (plná). Parametr <shown> je pro všechny hraniní kivky kižovatky nastaven na 0, typ <type> jednotlivých kivek závisí na tom, zda se jedná o kivku hraniící s ramenem kižovatky (taková kivka je nastavená jako perušovaná) nebo o ást hranice, kterou není možné pejíždt (plná). Popis kižovatky obsahuje také popis všech bunk pro prjezd vozidel, které jsou v kižovatce nadefinovány. Buka 11

18 2 Systém JUTS <place> je urena svým identifikátorem <placeid> a bodem oznaujícím pozici, na které je umístná <point>. Na obrázku 2.13 b) jsou naznaené možné pozice bunk definovaných v kižovatce. a) b) Obr. 2.13: Popis kižovatky: a) poadí bod vkládaných do hraniních kivek; b) možné pozice bunk v kižovatce definovaných pro prjezd vozidel kižovatkou. Oblast pro popis generátor obsahuje jednotlivé generátory obsažené v map <GenGraphicItem>. Každý generátor je urený identifikátorem <genid> a bodem, na kterém je umístný <point>. Generátory mají za úkol emitovat vozidla do simulaního systému. Stejnou strukturu jako generátory mají v popisu i všechny terminátory, v souboru se mírn liší jen používané znaky XML. Každý terminátor <TermGraphicItem> má tedy svj identifikátor <termid> a bod <point>. Pes terminátory vozidla opouštjí simulaní systém, jsou v nm evidována a jejich objekty rušeny. Funknost generátor a terminátor zajišuje simulaní jádro, editor pouze popisuje jejich umístní Simulaní ást simulaní mapy Posledním souborem, se kterým grafický editor pracuje, je druhá, simulaní, ást mapy, kterou editor vytváí v XML formátu. Tato struktura je opt znázornna ve form stromu, rozdleného na nkolik ástí, na obrázcích Jedná se o logickou strukturu uchovávající vzájemné návaznosti mezi jednotlivými ástmi mapy. Tato ást mapy neobsahuje žádné grafické informace, žádné souadnice. Ty jsou uloženy v grafické ásti a jsou simulátoru dostupné pes identifikátory, které jsou editorem piazené jednotlivým elementm mapy. a) 12

19 2 Systém JUTS b) c) d) 13

20 2 Systém JUTS e) Obr. 2.14: Struktura XML ve form stromu: a) základní struktura; b) až e) podrobnjší struktura jednotlivých ástí. Celý systém pidlování identifikátor má nkolik základních pravidel, která je pi vytváení a pidlování identifikátor teba dodržovat: identifikátor elementu je v celé map jedinený, tzn. není možné, aby se v jedné map vyskytovalo více element se stejným ID, identifikátor je vždy pouze íselný a skládá se vždy z devíti íslic, první ti íslice urují typ elementu, kterému je identifikátor pidlen, a to takto: 110 RoadItem silnice 111 ParkLane parkovací pruh 112 VehicleLaneItem jízdní pruh 113 RailLaneItem tramvajový pruh 120 CrossRoadItem kižovatka 121 PlacesItem buka v kižovatce 130 RoundAboutItem kruhový objezd 140 GeneratorItem generátor 150 TerminatorItem terminátor 160 ParkingItem parkovišt 210 AccessItem prvek pro propojení jízdního pruhu a kižovatky, pop. jízdního pruhu a generátoru nebo terminátoru. Systém mže obsahovat i jiné identifikátory pro servery a ídící elementy. Ty však nejsou vytváeny grafickým editorem, ale jsou do mapy dodávány v jiných ástech 14

21 2 Systém JUTS systému JUTS, proto zde nebudou popisovány, stejn jako ty ásti souboru, které grafický editor sám nevytváí (nap. <simulation>). Koenový element <map> v sob obsahuje ást pro uvedení informací o map <MapInfo>, která obsahuje jméno <name> a popis <description> mapy. Další ástí XML souboru jsou informace pro simulaci <simulation>, dále pak popis propojovacích míst <AccessPlaces>, ást pro parkovišt <parkings> a ídící objekty <controlers>. S parkovišti ani ídícími objekty editor ani simulátor v souasné dob nepracují, budou zapracovány až v nkteré z následujících verzí. V poslední ásti souboru je vložena logická struktura všech segment mapy <segments>. Podrobnji je tedy zapotebí popsat propojovací místa a strukturu tvoenou segmenty mapy. Popis propojovacích míst <AccessPlaces> se skládá z jednotlivých položek. Každé propojovací místo <AccessItem> má svj identifikátor <id> a krom ady vtšinou prázdným tag pipravených pro rozšíení funknosti, jsou pro popis propojení dležité ješt elementy: <successor> pedchdce a <predecessor> - následník. Jak následník, tak pedchdce jsou ureny identifikátorem <id> a pozicí <position>. Následníkem nebo pedchdcem propojovacího místa mže být jízdní pruh nebo místo v kižovatce. Jako identifikátor pedchdce a následníka je tedy vždy uložen identifikátor píslušného elementu (jízdního pruhu nebo buky v kižovatce). Pozice buky v kižovatce je vždy rovna nule, jinak je tomu však v pípad jízdního pruhu (jak je naznaeno na obrázku 2.15). V závislosti na délce jízdního pruhu je možné ho rozdlit na uritý poet úsek po 2,5 m. Délka 2,5 m je základní velikostí buky celulárního automatu a je odvozena z platných norem ministerstva dopravy [Hart1]. Pokud íslo pi dlení délky pruhu velikostí úseku nevyjde jako celá hodnota, je použito nejbližší nižší pirozené íslo. Získané úseky lze považovat za pozice v jízdním pruhu. Jestliže budeme tyto pozice íslovat od nuly ve smru jízdy, získáme tak na zaátku jízdního pruhu pozici 0 a na jeho konci pozici n-1, kde n je práv zmiovaný poet úsek. Takto získaná hodnota pozice je použita pro element <position> v pedchdci, pop. v následníkovi propojovacího místa. Záleží pouze na tom, kde se konkrétní popisované propojovací místo nachází. Ve struktue XML je opt uvedeno nkolik dalších vlastností, ty však nijak nezávisí na vlastním grafickém editoru. Pi generování jsou bu zadány jako konstantní hodnota, nebo jsou ponechány prázdné. Obr. 2.15: Zpsob získání hodnoty pro element <position> v popisu propojovacího místa. ást pro popis segment v map má oproti pedchozí ásti výrazn složitjší strukturu. Ješt ped samotným popisem segment je uveden jejich celkový poet <number>. Poté následuje definice silnic <roads>, kižovatek <CrossRoads>, kruhových objezd <roundabout>, generátor <generators> a terminátor <terminators>. 15

22 2 Systém JUTS Nejdíve jsou v souboru popsány jednotlivé silnice <RoadItem>. Na zaátku je silnici zadáno nkolik obecných informací jako jsou identifikátor <id>, jméno <name>, délka <length>, udávající poet 2,5 metrových úsek, které by se do silnice vešly, a maximální možná rychlost <MaxSpeed>. Po obecných informacích následují definice jízdních pruh <VehicleLanes>. Za položky, které stojí za zmínku u jednotlivých jízdních pruh <VehicleLaneItem>, považuji identifikátor jízdního pruhu <id> a jeho délku <length> (poet 2,5 metrových úsek v jízdním pruhu). S dalšími položkami pro popis jízdních pruh grafický editor nepracuje. Pro každou silnici jsou v souboru dále pipravené elementy pro popis ady dalších vlastností, nap. tramvajové nebo parkovací pruhy apod. Podstatnými v popisu každé silnice jsou ješt seznamy všech akceptor <acceptors> a emitor <emitters>, piléhající k jednotlivým jízdním pruhm silnice. Za akceptory jsou považována taková propojovací místa, která akceptují vozidla ze silnice, tzn. vozidla ze silnice do nich vjíždí. Emitory jsou naopak ta propojovací místa, která vozidla do silnice emitují. Emitory i akceptory jsou ureny svými identifikátory <id>. Umístní akceptor a emitor vzhledem k jízdnímu pruhu je názorn ukázáno na obrázku 2.16 a). Popis každé kižovatky <CrossRoadItem> zaíná, stejn jako popis jednotlivých silnic, obecnými informacemi <CrossRoadSingleVar> jako je identifikátor <id>, jméno <name> a maximální rychlost <MaxSpeed>. Stejn jako silnice obsahuje také seznam akceptor <acceptors> a emitor <emitters>. V tomto pípad je ale význam propojovacích míst brán z pohledu kižovatky a nikoli jízdního pruhu (viz obrázek 2.16 b). Z toho logicky vyplývá, že pokud bylo propojovací místo z pohledu silnice akceptorem (vozidla z jízdního pruhu do nho vjíždla), z pohledu kižovatky je totéž místo bráno jako emitor (vozidla z nho do kižovatky vyjíždjí). V každé kižovatce je v map definována ada smr pro prjezd danou kižovatkou. Tyto smry jsou ureny pomocí tzv. bunk v kižovatce <places>. Každá buka <PlaceItem> má stejn jako ostatní elementy mapy svj jedinený identifikátor <id>. Zárove je pro buku uložen seznam všech možných smr <NextPlaces>, kterými lze z buky pokraovat v jízd kižovatkou. Každá položka seznamu <NextPlaceItem> se skládá z identifikátoru následujícího prvku mapy <id> a smru (pesnji eeno akceptoru kižovatky v daném smru) <direction>. Píklad definice a následný popis situace v XML souboru je znázornn na obrázcích Jako následující prvek pro buku v kižovatce mže být dáno bu jiná buka, pop. nkterý z akceptor. V takovém pípad se hodnoty zadané pro <id> a <direction> shodují. a) b) Obr. 2.16: Rozdlení propojovacích míst na emitory a akceptory z pohledu a) silnice; b) kižovatky. 16

23 2 Systém JUTS a) b) <places> <PlacesItem> <id>10</id> <NextPlaces> <NextPlaceItem> <id>1</id> <direction>1</direction> </NextPlaceItem> <NextPlaceItem> <id>11</id> <direction>5</direction> </NextPlaceItem> </PlacesItem> <PlacesItem> <id>11</id> <NextPlaces> <NextPlaceItem> <id>13</id> <direction>5</direction> </NextPlaceItem> <NextPlaceItem> <id>13</id> <direction>7</direction> </NextPlaceItem> </PlacesItem> <PlacesItem> <id>12</id> <NextPlaces> <NextPlaceItem> <id>7</id> <direction>7</direction> </NextPlaceItem> <NextPlaceItem> <id>10</id> <direction>1</direction> </NextPlaceItem> </PlacesItem> <PlacesItem> <id>13</id> <NextPlaces> <NextPlaceItem> <id>5</id> <direction>5</direction> </NextPlaceItem> <NextPlaceItem> <id>12</id> <direction>7</direction> </NextPlaceItem> </PlacesItem> </places> c) Obr. 2.17: Ukázka popisu navazujících bunk v kižovatce: a) íslování element; b) definice smru jízdy; c) píklad XML. ást popisu kruhových objezd je v souasné dob prázdná, doplnní systému pro kruhové objezdy je ureno pro další rozšíení. Popis generátor <GeneratorItem> a terminátor <TerminatorItem> má podobnou strukturu. Každý je uren identifikátorem <id>. Ten je v pípad generátor zanoen do elementu <GenSingleVar>, u terminátor pak <TermSingleVar>. Pro generátory je dále znakou <acceptors> uren identifikátor <id> propojovacího místa <acceptors>, pes který je generátor pipojen k jízdnímu pruhu. Totéž propojení existuje u terminátor, liší se pouze použitá znaka, místo akceptoru je propojovací místo oznaeno jako emitor <emitters>. V popisu struktury souboru nejsou uvedeny všechny znaky, které se mohou v XML objevit. Vtšinou se jedná o prázdné elementy nebo elementy s konstantn zadanou hodnotou, na kterou nemá grafický editor žádný vliv. Popis všech tchto znaek by nijak neprospl zpehlednní a zlepšení pochopení struktury souboru z pohledu grafického 17

24 2 Systém JUTS editoru. I když byl formát souboru dohodnutý ped vlastním zahájením tvorby jednotlivých ástí systému, stále v nm dochází k drobným zmnám a úpravám. Struktura souboru je tedy ješt stále v pracovní verzi. Ped úplným dokonením souboru bude ješt zapotebí odstranit nadbytené elementy, které byly na zaátku navrženy a v prbhu vývoje se pestaly používat. Bylo by také vhodné ujednotit názvy jednotlivých znaek, zejména používání malých a velkých písmen. Všechny tyto úkony upravující strukturu souboru však vzhledem k tomu, že je soubor naítán simulaním jádrem, závisí na implementaci simulátoru. Grafický editor nemže strukturu XML souboru nijak ovlivnit, podléhá požadavkm simulátoru. 18

25 3 GIS systémy 3 GIS systémy 3.1 Existující prostedky Pro práci s geografickými daty je ureno velké množství produkt. Podle [Cajt] se jen v R tvorbou GIS (geografických informaních systém) pro veejnou správu a samosprávu zabývá pes 20 firem (nap. Bentley, Intergraph, ESRI, Foresta, Gepro,...). Základní funkce GIS systém jsou ve vtšin pípad velmi podobné. Systémy se liší ve velikosti území, se kterým je možné pracovat, nkteré jsou použitelné v obecnjším smyslu, jiné jsou pomrn úzce specializované na konkrétní oblast lidské innosti nap. lesní hospodáství nebo zpracování konkrétních adresních míst. V závislosti na obecnosti a rozsahu systému uvádí [Cajt] možnost dlení GIS do dvou základních skupin. Do první skupiny patí velké obecné GIS, které uživateli nabízejí znané množství funkcí a ke kterým se pidáváním dalších aplikací dopluje další funknost. Tyto systémy neomezují uživatele svou úzkou specializací a nižší funkností, jsou však pomrn finann nároné. Patí mezi n napíklad produkty firem Intergraph (WebCity), Bentley (Microstation), apod. Do druhé skupiny se pak adí systémy s nižší funkností, ale zárove s nižší poizovací cenou. Jejich funknost vtšinou postauje konkrétním potebám uživatele a zárove se jedná o finann dostupnjší systém. Nevýhodou tchto systém mže být však špatná kompatibilita formát datových soubor mezi rznými systémy. Dvodem je používání vlastních formát pro uložení grafických dat. Mezi tyto samostatné produkty patí napíklad systémy firem Gepro, s.r.o. (MISYS, Kokeš) nebo Foresta SG, a.s. (PUKNi2) a další. Editor schémat uliních graf, který vznikl ve spolupráci s Úsekem koncepce a dopravního inženýrství Správy veejného statku msta Plzn [URL2] a Správou informaních technologií msta Plzn [URL3], by bylo možné zaadit práv do výše uvedené druhé skupiny produkt. Jedná se o siln specializovaný systém pro vytváení mapy, který v sob musí spojovat nkteré ovládací prvky používané v bžných grafických editorech a speciální funkce sloužící pro práci s mapou a jejími ástmi kižovatkami, silnicemi, apod. V prbhu vytváení grafického editoru se objevily informace o existenci systému pro simulaci dopravy, jehož souástí je i grafický editor urený pro pípravu kižovatek a silniní sít. Jedná se o program pro mikroskopickou simulaci dopravy AIMSUN a editor komunikaní sít TEDI [URL4]. TEDI je rozsáhlý produkt umožující pípravu kižovatek i silnic pro mikroskopickou simulaci. Stejn jako grafický editor JUTS pracuje s elementy na úrovni jízdních pruh a definice smru jízdy v kižovatkách. Narozdíl od grafického editoru JUTS umožuje dále také editaci složitjších dopravních uskupení jako jsou napíklad kruhové objezdy nebo dálnice, jízdní pruhy pro MHD, vetn možnosti pipojení aktuálních jízdních ád, umožuje zaazení semafor, definici rychlosti jízdy v konkrétních úsecích, rychlosti jízdy pro odboování, sklonu vozovky, reakní doby idi,... Dále nabízí uživateli export dat do formátu standardního pro import do GIS. Celý tento simulaní projekt pracuje na ásten odlišné filosofii v porovnání se systémem JUTS. Zatímco v systému JUTS slouží grafický editor pouze k píprav mapy, její grafické úprav a vzájemnému logickému propojení jejích jednotlivých element, a samotná data pro simulaci jsou pak spolen s mapou vkládána v zadaném formátu pímo do simulaní ásti systému, editor TEDI vkládá do mapy pímo také informace o intenzit 19

26 3 GIS systémy dopravy v jednotlivých úsecích. Pítomnost informace o hustot provozu by mohla podle mého názoru omezit možnosti testování rzných dopravních situací v daném míst (nap. zmnu provozu v dsledku uzavení paralelní komunikace, popípad situaci, kdy by v daném míst došlo k dopravní nehod apod.). Vzhledem k tomu, že jsem však nemla možnost vyzkoušet si innost simulátoru ani grafického editoru osobn, nemohu tuto domnnku podložit praktickými zkušenostmi. 3.2 Funknost, výbr vhodných funkcí Jak jsem již zmínila v kapitole 3.1, velká ást GIS systém se shoduje zejména v základních funkcích. ada tchto funkcí bývá zárove i bžnou souástí nespecializovaných grafických editor. Jedná se pedevším o funkce umožující práci s pohledem (výbr oblasti, zoom, skrývání jednotlivých ástí mapy), možnost výbru jednotlivých zobrazovaných element, práce se soubory apod. GIS kladou velký význam na pesnost souadných systém, asto také nabízejí možnost pro volbu konkrétního souadného systému. Odlišnosti jednotlivých GIS je možné hledat také v závislosti na velikosti zpracovávaného území a úelu zpracovávání (tvorba mapy, zpracovávání statistik obyvatelstva,...). Systémy poskytují uživateli další funkce jako výpoty výmry oblastí a vzdáleností, vzájemných vztah a pozic element a jiné geodetické a konstrukní funkce, umožují pesné nastavení mítka, nabízí práci s ernobílými i barevnými rastry, umožují vektorizaci objekt, tvorbu 3D model apod. Nemén dležitým hlediskem pi kategorizaci GIS je také velikost a detailnost zpracování území. Nkteré systémy jsou vhodné pro práci s daty pro území jednoho nebo nkolika stát, jiné pracují se souadnicemi jednotlivých parcel, silnic, plochami lesních porost a jinými geografickými prvky. Nkteré systémy jsou pímo pomrn úzce specializované na konkrétní oblast lidské innosti nap. lesní hospodáství nebo zpracování konkrétních adresních míst, jiné pracují na obecnjší bázi. V závislosti na všech tchto faktorech a po konzultaci se studenty a pracovníky katedry matematiky ZU, odborníky v oblasti GIS, jsem se rozhodla jako referenní software pro svoji diplomovou práci zvolit systém Kokeš for Microsoft Windows, produkovaný firmou GEPRO s.r.o. Tento software detailn pracuje s nejrznjšími geografickými elementy (zástavba, parcely,...). Velikostí zpracovávané oblasti a detailností úprav jednotlivých prvk tedy odpovídá parametrm uliního grafu. Dalším dvodem pro volbu systému Kokeš byla spolupráce odborník FAV ZU na jeho vytváení. Abych mohla tento systém použít jako referenní, bylo nutné se seznámit s jeho funkcemi a možnostmi. Mojí základní snahou bylo získat maximum informací týkajících se ovládání a stylu práce. Snažila jsem se najít takové funkce, které uživateli práci v editoru zjednodušují a urychlují. Tyto informace jsem získávala nejen vlastním zkoumáním programu a tením dokumentace k systému Kokeš [GepDoc], ale také spoluprací s tmi, kteí tento systém bžn používají. Bhem mnoha konzultací jsem tak získala adu námt a doporuení, kterých jsem se bhem tvorby grafického editoru snažila držet. 20

27 4 Návrh editoru 4 Návrh editoru Grafický editor schémat uliních graf slouží k vytváení map pro systém JUTS. Systém umožuje natení všech potebných vstupních dat, jejich úpravu a doplnní o další údaje. Jako vstupní data jsou používána skutená geografická a dopravní data msta Plzn, která byla poskytnuta Správou informaních technologií msta Plzn [URL3]. Po dokonení editace uliního grafu lze výslednou mapu exportovat do souboru pesn popsaného XML formátu, který je možné použít jako vstupní soubor pro JUTS. Formáty všech vstupních i výstupních soubor jsou podrobn popsány v kapitole 2.2 Formáty soubor. Pi návrhu samotného grafického editoru jsem vycházela z poznatk získaných dkladným prostudováním referenního GIS Kokeš for Microsoft Windows i v závislosti na zkušenostech s prací v obecných grafických editorech. Nkteré funkce bylo teba zahrnout do systému nezávisle na jakýchkoliv již existujících systémech. Jedná se o funkce související s úzkou specializací programu, napíklad úprava silniní sít nebo definice smr pro jízdu kižovatkou. Po zvážení všech potebných a vhodných funkcí bylo nutné z dvodu pehlednosti jednotlivé funkce logicky rozlenit do kategorií a navrhnout samotné grafické rozhraní editoru (podrobnjší popis návrhu grafického prostedí popisuje kapitola 4.1). Poté následovala implementace jednotlivých algoritm (viz kapitola 4.2) a funkcí (popsány v kapitole 4.3). Pvodn navržená funknost i vzhled procházely bhem implementace upesujícími zmnami a úpravami. V dále uvádných vzorcích vtšinou nebudou detailn vysvtleny jednotlivé promnné, vztahy nebudou odvozovány píliš podrobn. Je to z dvodu jednoduchosti vztah a jejich všeobecné známosti. 4.1 Návrh grafického prostedí Pi prostudovávání referenního systému i procházení bžných grafických softwar, bhem vytváení návrhu i následné implementace jsem se snažila, aby samotné používání jednotlivých funkcí a celková píprava mapy byly maximáln intuitivní. Cílem bylo vytvoit snadno ovladatelný a pehledný editor pro zadaný úel vytvoení silniního grafu ze zadaných vstupních dat a jeho export do výstupních soubor s odpovídajícím XML formátem. Ped samotným návrhem grafického prostedí bylo nutné rozhodnout, jakým zpsobem bude vlastn celý proces vytváení mapy probíhat, jaká innost bude od uživatele vyžadována a v jakém rozsahu, zda bude vytváení mapy probíhat klikacím nebo dávkovým zpsobem a jestli bude závislé jen na uživateli, nebo bude ásten automatizováno. Pi koneném rozhodování jsem se piklonila k jedinému hlavnímu oknu, ve kterém jsou umístny všechny grafické ovládací prvky menu, nástrojové lišty, šipková ržice, i samotná kreslicí plocha. Aby byla uživateli umožnna co nejpohodlnjší práce, umožuje editor nejrznjší nastavení vykreslování (barva, styl, velikost). Zárove lze skrývat a optovn zobrazovat jednotlivé ovládací prvky. Tím je umožnna alespo ásten variabilní velikost pracovní plochy. Rozmístní ovládacích prvk v okn za pedpokladu, že jsou všechny zobrazené, je popsáno na obr Grafický editor vytváí mapu poloautomaticky, s nutnými zásahy uživatele v okamžicích vyžadujících kontrolu stavu, pop. doplnní informací, které nejsou systému 21

28 4 Návrh editoru dodány ve vstupních datech, jako nap. piazení reálných kižovatek ke kižovatkám silniní sít nebo definice smr pro prjezd kižovatkou. Editor sám provádí urité kontroly správnosti stavu mapy, a pokud je to nutné, na pípadné chyby uživatele upozorní. Bhem pechod je automaticky generován vzhled mapy a následn je uživateli umožnna dodatená korekce automaticky vygenerovaného stavu a doplnní potebných informací. Styl práce je závislý zejména na používání myši, systém obsahuje velké množství klávesových zkratek. Celou mapu je ale možné vytvoit také pouze pomocí pohybu a klikání myši. Obr. 4.1: Rozmístní všech grafických ovládacích prvk v hlavním okn editoru. 4.2 Algoritmy využívané editorem Bhem vytváení mapy využívá editor nkolik algoritm pro vyhledávání, urení pozice nebo automatické generování. Následující podkapitoly urují pehled jednotlivých algoritm, jejich popis a vysvtlení s názornými ukázkami na obrázcích. Konkrétní použití algoritm ve funkcích editoru je popsáno spolen s funkcemi editoru v kapitole 4.3 a dále pak v píloze A Uživatelská dokumentace, v kapitole o typickém postupu pípravy mapy od A do Z, která se zabývá postupem vytváení mapy v grafickém editoru. Grafický editor pracuje zárove se dvma souadnými systémy souadným systémem kreslicí plochy (tento systém se používá pi vykreslování, zjišování pozice kurzoru v kreslicí ploše apod.) a souadným systémem uliního grafu (pozice uzlových bod, celkové rozmry mapy,...) Proto je nutné asto používat pepoet mezi obma systémy. Zpsob pepotu je souástí popisu pro výbr uzlového bodu v podkapitole

29 4 Návrh editoru Vytvoení silniní sít Algoritmus slouží k automatickému vytvoení sít silnic ze vstupních dat natených na zaátku vytváení nového uliního grafu. Podstatné jsou oba soubory v textovém formátu (první udávající ohraniující obdélníky segment silnic a druhý obsahující souadnice uzlových bod; pesný popis jejich formátu je uveden v kapitole 2.2). Pro vytvoení silniní sít je poteba vyhledat souvislosti mezi jednotlivými uzlovými body a hranicemi segment a zárove zajistit správné natoení segment silnic (ohraniující obdélník segmentu silnice udává oblast, ve které se mže daný segment vyskytovat). V rámci ohraniujícího obdélníku mže být segment libovoln zakivený, jeho koncové body jsou však vždy umístny na hranici dané obdélníkem (píklady viz obr. 4.2). Koncové body segmentu silnice jsou zárove totožné se dvma uzlovými body zadanými v druhém datovém souboru. Je tedy nutné pro každý natený segment vyhledat práv dva odpovídající uzlové body, mezi kterými je segment proložen ve tvaru úseky. Použitím aproximace dochází k ástené ztrát pesnosti oproti reálnému tvaru segmentu, informace o pesném tvaru však není ve vstupních datech. Vzhledem k tomu, že však naprostá vtšina reálných úsek odpovídá situaci na obrázku 4.2 a), b), poskytuje tato aproximace pro simulaci dostatenou pesnost. a) b) c) d) Obr. 4.2: Aproximace segmentu silnice úsekou pvodní tvar je zobrazen šedou kivkou, aproximace pak ernou úsekou. Pro každý segment jsou tedy vyhledány dva uzlové body a zárove jsou navzájem propojeny odkazy. Jakmile jsou prohledány všechny segmenty obsažené v datovém souboru, vznikne silniní sí se vzájemnými vazbami mezi segmenty a uzlovými body. Vzhledem k malému potu segment obsažených v datových souborech by pedzpracování dat a následné použití rychlejšího algoritmu pro vyhledávání odpovídajících uzlových bod pravdpodobn nemlo zásadní vliv na rychlost zpracování. Urychlení by bylo patrné pi výrazném nárstu potu segment a uzlových bod (ádov alespo pro stovky objekt). Tyto poty jsou v závislosti na zadání v souasné dob málo pravdpodobné Výbr uzlového bodu V prbhu úpravy mapy v prvním editaním kroku musí mít uživatel možnost upravovat pozice uzlových bod, popípad jednotlivé body mazat. Je tedy zapotebí algoritmus, který by v závislosti na zadání souadnic kurzoru zjistil, zda je zadaná souadnice v oblasti uzlového bodu, pop. který uzlový bod má k pozici kurzoru nejmenší vzdálenost. Výbr zvoleného uzlového bodu z mapy je provádn pepotem souadnic a následným vyhledáním takového existujícího uzlového bodu, který se na dané souadnici nachází. Po kliknutí myší do oblasti mapy se v závislosti na mítku zobrazení a posunu výezu mapy pepoítají souadnice bodu do geografického souadného systému podle vztah uvedených níže (1). Získané geografické souadnice jsou s tolerancí odpovídající 23