Masarykova univerzita

Masarykova univerzita

Fakulta informatiky

Informační systém pro kontrolu silnic

2010, Brno Jakub Dubrovský

Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval(a) samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal(a) nebo z nich čerpal(a), v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Vedoucí práce: RNDr. Milan Drášil, CSc.

Poděkování Děkuji svému vedoucímu práce za vstřícný přístup a za volnost, kterou mi poskytl. Děkuji svému otci, bez kterého by nevznikl nápad na vytvoření informačního systému. Děkuji všem, kteří se na vývoji a testování podíleli a podílejí. Děkuji svým blízkým za podporu, kterou mi poskytují.

Shrnutí Cílem práce je provést analýzu kontroly silnic v České republice dle zákona 13/1997 Parlamentu České republiky o pozemních komunikacích a vyhlášky číslo 104/1997. Výsledkem práce je návrh informačního systému, který podpoří kontrolu silnic a předávání informací mezi pověřenými osobami. Osoba pověřená kontrolou silnic při prohlídce pomocí navrženého rozhraní využívající GPS přijímač zaznamenává nově nalezené závady. Systém automaticky vyplní údaje o přibližné poloze závady na základě znalosti GPS pozici. Systém odešle zprávu firmě pověřené údržbou silnic o nové závadě. Vlastník komunikace sleduje stav komunikací. V systému vyhledává závady a zobrazuje je na mapě.

Abstract The goal is to analyze road monitoring in the Czech Republic according to Act 13/1997 of the Czech Republic on the road and Decree number 104/1997. The result of this work is design an information system to support the inspection of roads. Person responsible for road monitoring records the newly discovered defect. The system automatically fills in the details of the approximate location thanks known GPS position. Then the system sends a message to the company responsible for maintaining roads. Owner monitors the state of roads.

Klíčová slova informační systém, kontrola silnic, web map servis, mapy, GPS, ERD, XML Keywords information system, roadware, web map servis, maps , GPS, ERD, XML

Obsah 1. Úvod ......................................................................................................................................... 1 1.1 Obsah práce .......................................................................................................................... 1 1.2 Motivace ............................................................................................................................... 1 1.3 Kontrola silnic ...................................................................................................................... 2 2. Legislativa ................................................................................................................................. 3 3. Konceptuální analýza a design.................................................................................................. 5 3.1 Požadavky na navrhovaný informační systém ..................................................................... 5 3.2 Stavový diagram životního cyklu závady........................................................................... 10 3.3 Datový model a design ....................................................................................................... 12 4. Implementace .......................................................................................................................... 16 4.1 Technologie serverové části ............................................................................................... 16 4.2 Technologie klientské části ................................................................................................ 17 4.3 Způsoby získávání geografických dat ................................................................................ 18 4.4 Možnosti uchovávání pozičních dat ................................................................................... 21 4.5 Výstup do zařízení GPS ..................................................................................................... 26 4.6 Výstup do souborů ............................................................................................................. 26 4.7 Práce se systémem .............................................................................................................. 26 5. Závěr ....................................................................................................................................... 30 5.1 Testovací provoz ................................................................................................................ 30 5.2 Vize .................................................................................................................................... 30 Citovaná literatura ........................................................................................................................... 32

1. Úvod 1.1 Obsah práce První kapitola představuje problematiku kontroly silnic v České republice, vysvětluje vybrané pojmy související s kontrolou silnic. Druhá kapitola představuje legislativu, podle které probíhá kontrola a údržba silnic. Shrnuje a poukazuje na vybrané části. Ve své práci se budu snažit vybrané části legislativy podpořit navrhovaným informačním systémem. Třetí kapitola se zabývá návrhem informačního systému SilniceNet. IS využívá více než padesát entit pro uchovávání informací o stavu IS a sebraných datech. ERD diagramy vysvětlují vztahy vybraných entit, jiné entity jsou jen zmíněné. Pro pochopení práce s IS je použit stavový diagram, který znázorňuje stav závady. Čtvrtá kapitola se věnuje implementaci systému. Popisuje vybrané technologie. Snaží se obhájit důvod volby a porovnat mezi ostatními. Je mnoho způsobů zobrazování pozičních dat, a proto obsáhleji jednotlivé popisuje a snaží se vybrat nejvhodnější. Pátá kapitola shrnuje přínosy IS. Popisuje dosavadní zkušenosti uživatelů s prací s IS. Nastiňuje další vývoj, jaké další procesy by měly být podpořeny.

1.2 Motivace Cílem této práce je návrh informačního systému pro kontroly technického stavu silnic v souladu s vyhláškou č. 104/1997 k silničnímu zákonu. Bude sloužit vlastníkům, správcům a osob pověřených ke kontrole silnic. Při návrhu informačního systému vycházíme z již existující aplikace MostařNet, webové databázové aplikace určené pro správce mostních objektů. Je určena zejména pro vedení mostních pasportů větších obcí nebo měst. Jelikož se podobný informační systém v době psaní této bakalářské práce v českém prostředí nenachází, je třeba se podrobněji seznámit s procesem kontroly silnic, s českou legislativou a diskutovat o této problematice s odborníky z oboru. Navrhuji informační systém pro uživatele, kteří dodnes preferují konzervativní zpracování informací pomocí tužky a papíru před složitou výpočetní technikou. Vedlejší ambicí této práce je tedy také změna přístupu uživatelů k uchovávání, poskytování a zpracování informací. Přesvědčit je, že použitím IT a vhodně navrženého informačního systému bude jejich práce nejen efektivnější, ale umožní jim také řešit daleko širší škálu potřebných úloh. Momentálně osoby pověřené kontrolou silnic komunikují se správci a vlastníky komunikací pomocí telefonu a elektronické pošty. Bohužel se může stát, že jednu závadu vyjede opravovat více firem. Záznam bývá veden v tabulkovém editoru bez pevně stanoveného formátu. Toto řešení je nesystematické. Zamezuje následnému strojovému zpracovávání, znemožňuje tvorbu statistik a vyhodnocování aktuální situace. Celkově se dá říci, že momentálně řešení je nejen nesystematické, ale i neekonomické.

1

1.3 Kontrola silnic Silnice jsou dopravní tepny země. Denně po nich jezdíme do zaměstnání, převážíme po nich čerstvé zboží do obchodních řetězců. Neodmyslitelně patří k našemu životu. Silnice, resp. informace o nich jsou ze své podstaty geograficky vztažené objekty, jsou pevně spojeny se zemským povrchem a jejich průběh je tedy reprezentovatelný geografickými souřadnicemi. Mnohdy si neuvědomujeme, že se o ně někdo musí pečlivě starat, kontrolovat silniční značení, opravovat výtluky, evidovat závady. V novinách čteme negativní zprávy o tom, jak jsou komunikace ve špatném stavu a nikdo se o ně nestará. Opak je pravdou, každý den kolem nás bez povšimnutí projíždějí pověřené osoby, které si všímají změn kolem vozovky, znají každý jejich úsek. Je to jejich práce. Zlepšení procesu kontroly silnic, lépe řečeno navržení informačního systému pro kontrolu silnic, se stal mou motivací bakalářské práce, a není tomu tak jen náhodou. Již několik let vyvíjím webovou databázovou aplikaci určenou pro správce mostních objektů.

2

2. Legislativa Seznam legislativy v ČR, kterou by měl připravovaný IS podpořit: 13/1997 Sb. zákon ze dne 23. ledna 1997 o pozemních komunikacích. Zákon upravuje kategorizaci pozemních komunikací, jejich stavbu, jejich užívání, práva a povinnosti vlastníků pozemních komunikací a jejich uživatelů, výkon státní správy ve věcech pozemních komunikací příslušnými silničními správními úřady. 104/1997 Sb. vyhláška Ministerstva dopravy a spojů ze dne 23. dubna 1997, kterou se provádí zákon o pozemních komunikacích. IS slouží pro evidenci stavu pozemních komunikací, což je cesta určená pro užití silničními a jinými vozidly. Silnice je veřejně přístupná pozemní komunikace. Podle dopravního významu jsou rozděleny do těchto tříd: silnice I. třídy, která je určena pro dálkovou dopravu, silnice II. třídy, která je určena pro dopravu mezi okresy, silnice III. třídy, která je určena pro spojení obcí nebo napojení na ostatní komunikace. Vlastníkem silnic je podle zákona o pozemních komunikacích: „Vlastníkem dálnic a silnic I. třídy je stát. Vlastníkem silnic II. a III. třídy je kraj, na jehož území se silnice nacházejí, a vlastníkem místních komunikací je obec, na jejímž území se místní komunikace nacházejí. Vlastníkem účelových komunikací je právnická nebo fyzická osoba.“ (1). V systému je označován rolí správa. V této roli vystupuje Ředitelství silnic a dálnic ČR (dále jen ŘSD ČR). Správce je osoba pověřená vlastníkem spravovat silnici. V systému je označován rolí údržba. V této roli bývá správa a údržba silnic (dále SÚS). Má na starosti silniční síť na svěřeném území. Mezi její hlavní činnosti patří odstraňování závad ve sjízdnosti komunikace a údržba silnic. Kontrola s pověřením správce vykonává pravidelné prohlídky silnic. V systému je označován rolí kontrola. V této roli bývá údržba nebo subjekt údržbou pověřený. Prohlídku zabezpečuje správce nebo vlastník komunikace, o jejím výkonu musí být veden záznam. (2) V dnešní době je většinou uložen pomocí tabulkového editoru, což pověřeným osobám mnoho neulehčuje práci s editací dat a vyhledáváním požadovaných záznamů. Běžnou prohlídkou je zjišťován stav dopravního značení, zabezpečovacích zařízení a závad ve sjízdnosti, musí být prováděna v pravidelných intervalech: dálnice a rychlostní silnice každý pracovní den, ostatní silnice I. třídy 2krát týdně, silnice II. třídy 2krát měsíčně, silnice III. třídy 1krát měsíčně (2). Hlavní prohlídka je prováděna při inventarizaci, nebo při uvedení nového úseku do provozu a před skončením záruční doby.

3

Mimořádnou prohlídku zajišťuje vlastník nebo správce komunikace při neočekávaných změnách stavu vozovky, při změně dopravního zatížení nebo při nutnosti získat pro systémy hospodaření s vozovkou. Informační systém by měl přispět ke zlepšení komunikace mezi organizacemi provádějící prohlídky silnic, organizacemi vykonávajícími údržbu a správci komunikací. Osobám provádějící kontrolou silnic by měl usnadnit evidenci závad. Podle silničního zákona „závadou ve sjízdnosti se rozumí taková změna ve sjízdnosti dálnice, silnice nebo místní komunikace, kterou nemůže řidič vozidla předvídat při pohybu vozidla přizpůsobeném stavebnímu stavu a dopravně technickému stavu těchto pozemních komunikací a povětrnostním situacím a jejich důsledkům.“ (2). Je zřejmé, že podle této definice jsou „závady ve sjízdnosti“ také geograficky vztažené objekty.

4

3. Konceptuální analýza a design 3.1 Požadavky na navrhovaný informační systém Jednou z prvních fází tvorby informačního systému je vytvoření seznamu požadavků, podle kterého bude systém vyvíjen. Požadavky lze rozdělit do tří skupin, na požadavky zařazené do návrhu, nezařazené do návrhu a možné vlastnosti nezařazené do návrhu. Každou skupinu dále můžeme členit na funkční a nefunkční požadavky. Funkční požadavky – představují očekávané funkce systému. Nefunkční požadavky – přímo nesouvisí s funkcemi systému, specifikují vlastnosti a omezení produktu. Požadavky byly probrány se zaměstnancem Ředitelství silnic a dálnic, který v roce 2007 pracoval jako kontrola silnic. Ze vzájemných rozhovorů vyplynuly základní požadavky na systém. Další rozhovory jsem vedl se zástupci firmy JAST s.r.o. Doudleby nad Orlicí, která se zabývá technickými činnostmi v dopravě. Pro ŘSD ČR, Správa Pardubice, provádí kontrolu silnic a následně i její údržbu. 3.1.1.1 Požadavky zařazené do návrhu Požadavky zařazené do návrhu jsou požadavky, které jsou závazné pro zhotovitele a budou kontrolovány a testovány při předávání softwaru. Funkční požadavky K prohlížení a editaci závad bude zapotřebí oprávnění na okruh, na kterém se závada nachází. Okruhem je myšlena trasa prohlídky kontroly. Výstup ze systému bude do formátu XLS, bude obsahovat informace o stavu a poloze závad. Výstup ve formátu XLS bude sloužit k tisku vybraných informací vyfiltrovaných závad. Systém bude nabízet výstup závad do formátu podporovaného v GPS zařízeních. Jednalo by se o formát GPX, který se používá hlavně v zařízeních firmy Garmin, a KML pro GPS navigace firmy Mio. Uživatel bude mít možnost prohlížet závady a okruhy na mapě. K editaci okruhů a závad budou zapotřebí patřičná oprávnění přidělená administrátorem. Bude možné importovat data z GPS zařízení. Pokud se bude jednat o zařízení značky Garmin, bude možné získat data přímo přes webové rozhraní. Jinak bude nutné, aby uživatel získal data s body zájmu z GPS zařízení a poté je importoval do systému. Nefunkční požadavky Uživatelé budou přistupovat do databáze pouze přes webové rozhraní. Evidence dat bude možná až po ověření osoby. Pro ukládání dat bude implementována volně dostupná databáze MySQL. Import a export polohopisných dat do GPS zařízení značky Garmin a Mio podporujících ukládání bodů zájmu do formátu GPX nebo KML. Pro programování aplikace bude zvolen programovací jazyk PHP.

5

3.1.1.2 Požadavky nezařazené do návrhu Skupina obsahuje požadavky objednavatele, u kterých netrvá na zařazení do návrhu. Zhotovitel se ujišťuje, že požadavky nebude muset plnit a při předávání nebudou kontrolovány. Funkční požadavky Uživatel k systému bude přistupovat pouze pomocí webového prohlížeče. Importování dat bude možné pouze z GPS zařízení, které ukládá body zájmu ve formátu GPX nebo KML. Přímý import dat, propojení GPS zařízení s informačním systémem, zajistím pomocí programu od společnosti Garmin. Bude nutné, aby jej měl uživatel nainstalován ve svém počítači a komunikaci s ním podporovalo jeho GPS zařízení. 3.1.1.3 Možné vlastnosti nezařazené do návrhu Jedná se o vlastnosti, které nejsou zařazeny do návrhu, ale o kterých se uvažuje a možná v další části vývoje budou implementovány. Funkční požadavky Pokud objednavatel pozitivně vyhodnotí nasazení GPS zařízení do procesu kontroly silnic, budeme se snažit přizpůsobit námi vybrané GPS zařízení jeho potřebám. Jednalo by se o vytvoření aplikace pro zařízení propojeného s GPS přijímačem, které by umožňovalo rychleji označovat závady během kontrolní jízdy pověřené osoby. Možnost zobrazovat vybrané závady na mapu určenou veřejnosti. Tím by mohl vzniknout webový portál informující uživatele o problematických silničních úsecích.

3.1.2 Uživatelské role a případy užití Pro znázornění komunikace uživatelů se systémem jsem použil Use Case Diagram neboli diagram užití. Diagram zachycuje hranice systému a uživatele komunikující se službami nabízenými systémem a vztahy mezi případy užití. Diagram se skládá ze základních částí: Aktor – znázorňuje externí subjekty spolupracující se systémem. Hranice systému – znázorněny jako obdélník. Ukazuje, čím se v systému budeme zabývat. Případ užití – proces systému, který může být vazbami provázan s ostatními komponentami diagramu. Asociace – vztah mezi aktorem a případem užití. Vazba „include“ – znázorňuje proces, který používá jiný proces.

Obrázek 1: Aktor

Obrázek 2: Vazba „include“

6

Obrázek 3: Případ užití

Obrázek 4: Vazba asociace

Z požadavků informačního systému vyplynuly uživatelské role sepsané níže. Předpokládá se, že uživatel je v dané roli autentizován, zadal uživatelské jméno a heslo a dále pracuje pod svoji identitou a oprávněním. Soupis byl doplněn o případy užití. Některé případy jsou podrobněji rozebrány

Obrázek 5: Diagram případu užití

7

3.1.2.1 Kontrola Hlavní funkce uživatele v roli kontrola je evidence závad. Vkládá záznamy a může (dle nastavení programu) určovat, kdo závadu odstraní, případně může provést záznam o operativním odstranění závady. Případy užití: Vkládání závad z GPS – bude umožněno sbírat data během prohlídky pomocí GPS zařízení a následně s nimi pracovat v systému. Evidence závad – každý uživatel bude moci prohlížet a upravovat závady, na které má přidělené oprávnění od administrátora. Bude upravovat informace o umístění, popis, návrhu opatření a zápisu odstranění závady. Export dat – uživatel potřebuje ukládat protokoly závad a tisknout.

Obrázek 6 Scénář práce se systémem uživatele v roli správa

3.1.2.2 Správa Česká Republika je rozdělena na správní jednotky, kterým přísluší pozemní komunikace. Uživatel v roli správa je vedoucím správní jednotky. Jednu správní jednotku může obsluhovat více subjektů. Případy užití: Evidence závad – uživatel je oprávněn provádět změny v zápisu správy závady. Správa okruhů – uživatel vytváří a edituje okruhy prohlídek. export dat.

8

Obrázek 7: Scénář práce se systémem uživatele v roli správa

3.1.2.3 Údržba Uživatel v roli „údržba“ bude prostřednictvím IS komunikovat se správcem silnic a domlouvat se na dalším postupu při opravování závad na silnicích. Většinou to bude právě on, kdo za peníze správce závadu opraví. Může se dostat do situace, kdy i on potřebuje v systému provádět evidenci závad. Bude pro něj přínosná možnost snadno filtrovat závady a následné je exportovat do různých formátů. Případy užití: Evidence závad – je oprávněn provádět změny v zápisu o odstranění závady, export dat.

Obrázek 8: Scénář práce se systémem uživatele v roli údržba

3.1.2.4 Administrátor Administrátor spravuje oprávnění uživatelů a komunikuje s uživatelem. 9

Případy užití: evidence uživatelů, přidělování práv, mazání označených závad ke smazání, komunikace s uživateli.

3.2 Stavový diagram životního cyklu závady Stavový diagram se používá pro popis stavů systému a přechody mezi nimi. Základní části diagramu jsou: Stav – znázorňuje v jakém stavu se systém nachází. Přechod – je propojení mezi jednotlivými stavy. Přechod je reakcí na událost. Nad každým přechodem může být popis. Pseudostav – jedná se o stav, kterým systém prochází bez zastavení (např. počáteční a koncový stav, spojení a rozvětvení). Stavový diagram znázorňuje stav jednotlivých závad v systému. Na základě stavu může se závadou pracovat určitý subjekt. Počáteční stavy jsou dva, buď kontrola vloží záznam do systému přes webové rozhraní, nebo jej vloží přes GPS zařízení a pak záznam doedituje v systému. Po ukončení editace kontrolou, podle nastavení systému záznam převezme správa a určí, kdo závadu opraví, nebo záznam převezme údržba, která závadu opraví. Po opravení závady přejde záznam do stavu opraveno, tím se stane neaktuálním.

10

Obrázek 9: Stavový diagram

11

3.3 Datový model a design Logický datový model byl navrhnut v aplikaci MySQL Workbench, která umožňuje pohodlnou správu modelu a následné generování SQL dotazů pro vytvoření a změnu databáze. Na ERD diagramu jsou zachyceny vztahy mezi některými entitami.

3.3.1 Vybrané entity IS obsahuje několik desítek entit, proto zde popisuji jen ty, které se nejvíce týkají ukládání závad.

Obrázek 10: ERD diagram

3.3.1.1 Závada Entita Závada obsahuje údaje o jednotlivých závadách. Předpokládaná mohutnost entity jsou tisíce záznamů. Denně v ní budou přibývat desítky nových údajů, následně neaktuální data budou automaticky přesunovány do entity Závada_y. Entita Závada_y a Závada_z se bude skládat ze stejných sloupců jako entita Závada. Do entity Závada_z budou ukládány průběžné změny na závadě, díky tomu uživatel bude moct sledovat historii editace. Jednotlivé sloupce jsou: oid – jedinečný identifikátor entity, prid – cizí klíč, odkazující na prohlídku během které byla závada označena, číslo silnice – typ varchar 10, úsek – číslo úseku, na kterém se závada nachází, uživatel údaj vybírá z entity Úsek, pořadí úseku – pořadí úseku na silnici, popis místa – popis místa kde se závada nachází, zeměpisná šířka – desetinné číslo souřadnic ve formátu WGS84, zeměpisná délka – podobně jako zeměpisná šířka,

okres – cizí klíč vázaný na číselník okresů,

12

číslo okruhu – cizí klíč vázaný na číselník okruhů, na základě tohoto údaje jsou uživatelům přidělovány oprávněním, čas – čas poslední úpravy závady, počasí – počasí při pořizování dat v terénu, sjízdnost – sjízdnost při pořizování dat v terénu, datum prohlídky – ve formátu YYYY-MM-DD,

kód závady – cizí klíč vázaný na číselník závad: o dopravní značka – otočená, o dopravní značka – povalená, o krajnice – rozjetá, o krajnice – výtluk, o kryt – výtluk, o kryt – vývar, o ostatní, popis závady, kdo provede – cizí klíč vázaný na číselník firem, závažnost – cizí klíč vázaný na číselník závažnost: o jiná závada příslušenství, o jiná závada vozovky, o nebezpečná závada sjízdnosti, o ostatní závada, o závada sjízdností,

návrh opatření, okamžité opatření,

pokyn majitele, kdo provede – cizí klíč vázaný na číselník firem, poznámka majitele, kdy provede – datum ve formátu YYYY-MM-DD, pokyn opravujícímu,

závadu odstranil – cizí klíč vázaný na číselník firem, datum odstranění – datum ve formátu YYYY-MM-DD, poznámka odstranění,

pid – cizí klíč vázaný na entitu Uživatel

13

stav řízení – cizí klíč vázaný na číselník stav: o nová závada o přijato správcem o opravit o přijato k opravě o opraveno new – příznak změny stavu, stav_kontrola – cizí klíč vázaný na entitu Uživatel, ID uživatele, který naposledy editoval údaje kontroly, stav_kontrola_date – datum poslední změny údajů kontroly, stav_sprava – cizí klíč vázaný na entitu Uživatel, ID uživatele, který naposledy editoval údaje správy, stav_sprava_date – datum poslední změny údajů správy, stav_udrzba – cizí klíč vázaný na entitu Uživatel, ID uživatele, který naposledy editoval údaje údržby, stav_udrzba_date – datum poslední změny údajů údržby, stav_vlozeno – cizí klíč vázaný na entitu Uživatel, ID uživatele, který vložil závadu, stav_vlozeno_date – datum vložení. 3.3.1.2 Prohlídka Entita Prohlídka obsahuje údaje o jednotlivých prohlídkách, cestách kontroly. Předpokládaná mohutnost entity jsou stovky záznamů. Denně v ní budou přibývat jednotky nových údajů. prid – jedinečný identifikátor entity, pid – cizí klíč vázaný na entitu Uživatel, číslo okruhu – cizí klíč vázaný na číselník okruhů, na základě tohoto údaje jsou uživatelům přidělovány oprávněním, čas – čas poslední úpravy závady, počasí – počasí při pořizování dat v terénu, sjízdnost – sjízdnost při pořizování dat v terénu, najeto km – počet najetých kilometrů během prohlídky, datum prohlídky – datum ve formátu YYYY-MM-DD. 3.3.1.3 Fotka Entita Fotka obsahuje údaje o fotkách závad, cestách kontrolora. Předpokládaná mohutnost entity jsou tisíce záznamů. Ke každé závadě budu pořízeno několik fotek. Fotky budou uloženy zvlášť, v tabulce budou o nich pouze informace. Denně v ní budou přibývat desítky nových údajů. ID – jedinečný identifikátor entity, file – název souboru, název – název fotky, typ – typ obrázku, možné jsou: JPEG, GIF, PNG, text- popis fotky, oid – cizí klíč vázaný na tabulku Závada, pid – cizí klíč vázaný na tabulku Uživatel, kde – příznak, zda se bude fotka zobrazovat ve fotodokumentaci k závadě,

14

c – pořadí fotky při zobrazování fotek určité závady, size – velikost fotky v bytech, width – šířka fotky v pixelech, height – výška fotky v pixelech, filename – původní název souboru. 3.3.1.4 Uživatel Entita Uživatel obsahuje údaje o uživatelích systému ve všech rolích. Předpokládaná mohutnost entity jsou desítky záznamů. V tabulce budou probíhat minimální změny. 3.3.1.5 Práva Entita Práva obsahuje práva přidělená uživatelům. Práva v systému jsou dělena na čísla okruhů a činnost, kterou v rámci okruhu může provádět, mezi činnosti patří: prohlížení závad, editace závad v roli kontrola, údržba, správa, a přidělování oprávnění dalším uživatelům Předpokládaná mohutnost entity jsou desítky záznamů. V tabulce budou probíhat minimální změny. 3.3.1.6 Číselník Entita Číselník obsahuje. Předpokládaná mohutnost entity jsou desítky záznamů. V tabulce budou probíhat minimální změny.

15

4. Implementace 4.1 Technologie serverové části Pro implementaci jsem si vybral sadu svobodného softwaru, který bývá označován zkratkou LAMP. Jde o operační systém Linux, webový server, databázový server MySQL nebo PosgreSQL a programovací jazyk PHP nebo Perl či Python. Jednotlivé technologie jsou na sobě nezávislé a jsou vyvíjeny samostatně. Toto řešení se používá převážně pro tvorbu webových aplikací.

4.1.1 PHP PHP je skriptovací programovací jazyk určen především pro dynamické webové prezentace. Původní význam zkratky byl Personal Home Page, nyní zkratka znamená Hypertext Preprocessor. Skripty jsou prováděny na straně serveru a klientovi je předána výsledná stránka. Syntaxe je inspirována programovacími jazyky Perl, C, Pascal a Java. Obsahuje mnoho knihoven, například na zpracování textů, práci se soubory, přístup k mnohým databázovým systémům a podporu práce s internetovými protokoly. Nyní je PHP ve verzi 5. Oproti předchozím verzím (verze 3 a 4) byla přepracována podpora objektově orientovaného programování. Nově je přidána možnost vytváření proměnných „private“ a „protected“ a tříd „final“ a „protected“. PHP skripty jsou kompilovány takzvaně při každém dotazu do interního formátu pro „PHP engine“. Při spočtení skriptů probíhá optimalizace a kešování kompilovaných skriptů pro rychlejší spouštění. Vlastnosti PHP jsou: používá „garbage collection“, dynamicky typované, možnost přímo zabudovat do HTML stránky, kvalitní podpora MySQL a jiných databází, umožňuje vytváření flexibilních polí, podpora procedurálního i objektově orientovaného programování, relativně jednoduché na pochopení, syntaxe je blízká jazyku C, rozšířenost a velká podpora komunity. Mezi hlavní nevýhody patří: jde o interpretovaný, ne kompilovaný jazyk, kdokoli má přístup k serveru, může nahlédnout do vašich kódů, nekonzistence vývoje.

16

4.1.2 MySQL MySQL je databázový server vytvořený švédskou firmou, nyní vlastněný společností Oracle Corporation. Jeho úspěch byl založen na jednoduchosti a rychlosti. Rychle se rozšířil ve webových aplikacích. Říkalo se o něm, že nepodporuje funkce, které by měla mít každá databáze (transakce, poddotazy, aj.). Nyní to již není pravda. Poptávka po pokročilejších funkcích v posledních letech z MySQL udělala kvalitní databázi. (3) Pro návrh a správu databáze jsem vybral nástroj MySQL Workbench, který si můžeme zdarma stáhnout ze stránek výrobce. Díky němu lze snadno navrhnout logický datový model a následně z něj vytvořit SQL dotaz pro generování změn v databázi. Nástroj podporuje „forvard a reverse ingeneering“ a vytváření dokumentace. Jde o velmi užitečný nástroj, který ušetří čas při práci s MySQL databází. (4)

4.1.3 XML XML je značkovací jazyk vhodný pro výměnu informací mezi systémy a pro ukládání dat. Jeho velkou výhodou je jednoduchost a čitelnost i pro člověka. Jeho nevýhodou bývá velikost generovaných dat. V systému budeme používat XML pro zobrazování dat na mapě a synchronizaci se zařízeními GPS. PHP 5 nabízí širokou podporu práce s dokumenty XML. Můžeme použít knihovnu SimpleXML, API SAX nebo přístup DOM. (5)

4.2 Technologie klientské části Rozhraní aplikace je napsané v HTML s CSS stylováním. Pro funkce na straně prohlížeče jsem si vybral javascriptovou knihovnu Greybox pro zobrazování fotek, Garmin Communicator Plug-in API pro komunikaci systému s GPS navigací a Openlayers pro zobrazování závad na mapě. 4.2.1.1 Garmin Communicator Plug-in API (6) Jde o javascriptovou knihovnu poskytující rozhraní mezi webovou stránkou, internetovým prohlížečem a navigací značky Garmin. Javascript funguje pouze ve webovém prohlížeči, nemůže pracovat se soubory na disku a s periferiemi. Pro fungování knihovny je nutné mít nainstalovanou aplikaci Garmin Communicator Plug-in, kterou si uživatel může stáhnout ze stránek firmy Garmin. Knihovna komunikuje přímo s aplikací a s navigací Mezi funkce knihovny patří: automatické rozpoznání zařízení připojeného k počítači, přístup k informacím o připojeném zařízení, čtení a ukládání tras, cest a trasových bodů z připojeného GPS zařízení, čtení fitness dat z připojeného fitness zařízení, čtení a ukládání souborů GPX a TCX, podpora Internet Explorer a Firefoxu na Microsoft Windows, podpora Safari a Firefoxu na Mac OS X. (6)

17

4.2.1.2 Openlayers Openlayers je volně dostupná knihovnu pro zobrazování prostorových dat z různých zdrojů v prostředí internetu šířená pod licencí BSD. Můžeme ji považovat za API sjednocující různé jiné API mapových poskytovatelů. Díky ní si například uživatel snadno vybere, zda chce data zobrazovat na mapách od společnosti Google nebo Microsoft. (7) Knihovna je napsána v javascriptu. Používá komponenty z knihoven Prototype a Rico. Ctí standardy mezinárodní standardizační organizace OGC. Organizace podporuje vývoj a implementaci standardů pro geoprostorová data. Mezi vstupní formáty patří například WMS,WFS,KML, GML a GPX. 4.2.1.3 Greybox Ke každé závadě bývá přiložena fotodokumentace. Naší snahou je poskytnout uživateli přehledné rozhraní pro prohlížení fotek, aniž by musel pro každou fotku načítat novou stránku. Zvolili jsme javascriptovou knihovnu Greybox, která nabízí jednoduché uživatelské rozhraní, malou velikost kódu (pouze 22KB), možnost změnu vzhledu pomocí CSS, jednoduchou instalaci a širokou podporu prohlížečů (Safari, Firefox 1.5+, Internet Explorer 5.5+, Opera 8.5+). Knihovna je šířena pod volnou LGPL licencí, díky které je zdarma použitelná. (8)

4.3 Způsoby získávání geografických dat V informačním systému budou uloženy údaje o poloze. Každá položka v pasportu by měla obsahovat číslo silnice, číslo úseku a volitelně GPS souřadnice. Snažím se popsat různé způsoby získávání dat z GPS zařízení a následně vybrat pro uživatele nejpřívětivější způsob s ohledem na pořizovací náklady.

4.3.1 Získávání dat z GPS navigace Uživatel bude v terénu ukládat data do své GPS navigace a následně je bude vkládat do systému. Naším cílem je tuto činnost co nejvíce zjednodušit. Bylo by velmi pracné, kdyby uživatel musel ke každé závadě opisovat GPS souřadnice ze svého zařízení. V tomto případě by uživatel tuto práci pravděpodobně odmítal dělat. Pokud po něm chceme tyto informace, musíme mu tuto činnost ulehčit. Uživatel by mohl do systému nahrát soubory z GPS zařízení, kde by byly uloženy souřadnice jednotlivých závad. Soubor by byl ve formátu GPX nebo KML. Systém by automaticky pro každou importovanou položku založil novou závadu. Následně by uživatel doeditoval údaje jednotlivých položek. Systém by se snažil podle GPS souřadnic uživatelovi nabídnout odpovídající hodnoty úseku a čísla silnice. Pokud by uživatel vlastnil GPS zařízení značky Garmin, pomocí Garmin Communicator Pluginu by přímo z IS získal snadno GPX soubor ze své navigace a dále by se postupovalo viz. výše.

4.3.2 Získávání ze zařízení s GPS přijímačem a s připojením na internet V dnešní době jsou dostupné mobilní telefony s integrovaným GPS přijímačem nebo přenosné počítače, ke kterým můžeme připojit GPS modul. Tím získáváme zařízení, které lze snadno připojit k internetu. Je více možností jak data uložit ze zařízení do IS. Patří mezi ně: prohlížeč s podporou HTML 5, 18

mobilní platformy na základě HTML, aplikace pro mobilní telefony Locify, aplikace pro počítač. 4.3.2.1 Internetový prohlížeč s podporou HTML 5 HTML 5 nabízí podporu získávání informace o pozici uživatele. Jde o snadnou implementaci pomocí javascriptových funkcí. Uživatel si nemusí na počítač instalovat další program, vystačí si se svým webovým prohlížečem. Prohlížeč se stane rozhraním mezi webovou stránkou a počítačem, ze kterého se snaží získat informaci o poloze. Prohlížeč s HTML 5 nemusí být nainstalovaný jen na počítači, ale i na mobilním telefonu. Je více způsobů, jak HTML 5 zjišťuje polohu. Polohu můžeme získávat z připojeného GPS přijímače, jde o nejpřesnější metodu, ale pro mobilní telefon energeticky nejnáročnější. Metodou určenou pro mobilní telefony je získávání informací na základě znalosti triangulace přibližné vzdálenosti od BTS (vysílač a přijímač radiových signálů). Tato metoda není tolik energeticky náročná. Přesnost je od jednoho bloku ve městech až po několik kilometrů v odlehlých krajinách. Poslední metoda je vhodná pro počítače, které mají pevnou IP adresu. Na základě MAC adresy prohlížeč určí pozici. Jde o přesnější metodu, než získávání lokality na základě IP adresy. (9) Momentální nevýhodou pro vývojáře je rozšiřitelnost podpory HTML 5 v prohlížečích. V počítači HTML 5 momentálně podporuje pouze Firefox 3,5 + a Chrome. Podpora je v mobilních telefonech na platformě Iphone 3.0 a Android 2.0. (10) Geografický systém používaný v HTML 5 je WGS84, žádný jiný systém není podporován. 4.3.2.2 Mobilní platformy na základě HTML Výrobci mobilních telefonů, a ne jen oni, si uvědomují jak důležitá je otevřenost pro vývojáře. Snaží se jim nabídnout co nejjednodušší cestu k vývoji aplikací na jejich mobilní zařízení. Výrobci (BlackBerry, Nokia, Palm) nabízejí vývojářům možnost napsat aplikace v upraveném HTML. Přidali speciální značky pro získávání dat z telefonu (kontakty, GPS, fotky, aj.). Vývoj pro každou mobilní technologii zvlášť je velmi nákladný. Pokud by prohlížeče v mobilních telefonech podporovali HTML 5, nemuseli by vznikat další řešení. Pokud chceme vyvíjet aplikaci pro mobilní telefony, ale nechceme programovat aplikaci pro každého výrobce zvlášť, můžeme zvolit platformu Locify. Locify je aplikace, která je dostupná pro většinu současných telefonů. Funguje jako webový prohlížeč, který dokáže přistoupit na připojený GPS přijímač. K pozičním údajům nepřistupujeme pomocí javascriptu, ale pomocí speciálních tagů. Výhodou platformy je její kompatibilita a snadnost implementace. Nevýhodou je nutnost připojení k internetu. (11) 4.3.2.3 Naprogramování vlastní aplikace pro získávání polohy Pokud máme specifické požadavky na získávání polohy, můžeme naprogramovat vlastní aplikaci. Nabízí se implementace Location API pro Java ME, kterou je API součástí. Java ME je určena pro mobilní telefony a PDA. Pomocí API můžeme přistupovat na GPS přijímač integrovaný v zařízení nebo připojený přes bezdrátovou technologii bluetooth. Rozhraní nám nabízí metody pro získávání pozičních dat.

19

Výhodou je rozšíření zařízení podporující Javu ME. Jde o implementačně složitější metodu, ale nemusíme se přizpůsobovat, můžeme vytvořit aplikaci podle našich představ.

4.3.3 Získávání dat z map Pokud uživatel nevlastní GPS zařízení a chce označit pozici záznamu, nabídneme mu mapové rozhraní, kde označí polohu objektu poklepáním na zvolené místo na mapě. Řešení je vhodné, pokud uživatel takto označuje maximálně několik záznamů týdně, ale ne pro několik záznamů denně. Získané poziční informace mohou mít horší přesnost zaměření, ale v některých případech jde o dostatečné řešení. Pokud již o záznamu máme nějakou poziční informaci, například číslo silnice, název vesnice a podobně, můžeme využít služby geocoding. Pomocí této služby upřesníme polohu záznamu. Uživatelovi nabídneme pouze výřez mapy, kde by se hledaný objekt měl nacházet (např. mapa okolí města Letohrad). Geocoding je proces přiřazování geografických souřadnic z názvů míst (názvy měst, řek, jezer, aj.). Můžeme vytvořit vlastní databázi míst, využívat veřejně dostupné API (Google Maps API) nebo si z internetu stáhnout již hotovou databázi. Projekt Geonames dovoluje zdarma stažení aktualizované databáze míst. Jde o celosvětovou kolekci zahrnující více jak 8 miliónů záznamů (v ČR kolem 20 tisíc).

4.3.4 Vybrané technologie Z výše zmíněných způsobů jsem pro implementaci vybral dva způsoby. Pokud uživatel vlastní mobilní telefon s GPS přijímačem, použije aplikace Locify. Jinak může označit místo závady na mapě. Scénář vkládání nových závad při prohlídce přes platformu Locify je následující: 1. v aplikaci Locify spustíme IS SilniceNet, 2. přihlásíme se pod přihlašovacími údaji shodnými s IS SilniceNet pro webový prohlížeč, 3. zvolíme číslo aktuálního okruhu, volitelně vyplníme informace o počasí a sjízdnosti, 4. při spatření závady vybereme druh závady a potvrdíme, 5. krok 4 opakujeme do skončení kontroly silnic. Na základě znalosti pozice závady jsme schopni zjistit číslo silnice a úseku. Pro upřesnění polohy byla použita databáze úseků ze Silniční databanky Ostrava. Při zjišťování čísla úseku a silnice procházím databázi úseků na okruhu (na obrázku značeno přerušovanou čarou), pokud je vzdálenost mezi závadou a koncem i začátkem (znázorněno kruhy se středy na kraji úseků) menší než délka úseku (na obrázku zvýrazněno černou čarou), nabídnu úsek uživateli. Pokud výběru odpovídá jediný úsek, uložím ho. Jelikož uživatel jede po stanoveném okruhu, je velká pravděpodobnost automatického určení úseku. Tímto ulehčíme práci kontrole s následující editací. Vkládání závad probíhá během jízdy. Navržené řešení vyžaduje jen málo vstupních informací. Po skončení prohlídky kontrolor doedituje záznamy v systému. Při přihlášení se zobrazí závady, které jsou pořízené přes aplikaci Locify. U nich je potřeba doplnit popis závady a další informace.

20

Obrázek 11: Způsob automatického získávání čísla úseku a silnice

4.4 Možnosti uchovávání pozičních dat 4.4.1 Relační databáze Většina používaných databázových strojů v současnosti podporuje geometrická data včetně efektivního přístupu k nim. I když prostorové rozšíření SQL databází vznikalo živelně a nepodléhá žádné normě SQL, syntax pro ukládání a výběr je "logicky" podobná a pro aplikace není výrazný problém přizpůsobit se jinému "prostorovému" DB stroji.

4.4.1.1 Vybrané řešení Pro ukládání dat jsem zvolil databázi MySQL. Výhodou je široká podpora ze strany PHP. Databáze podporuje základní operace s prostorovými daty a je dostupná na většině webhostingů.

4.4.2 XML Formát XML je vhodný pro přenos dat mezi aplikacemi. Například KML formát pro zobrazení dat v aplikaci Google Earth. Nehodí se pro ukládání a následné čtení dat, oprati SQL databázím. Obsahuje příliš mnoho metadat. Soubory jsou strukturovány, aby jim rozuměl i člověk a nejsou optimalizovány pro strojové čtení a ukládání. V systému je XML formát použit v pokročilých javascriptových funkcí, zobrazování dat na mapě a posílání dat do GPS zařízení. 4.4.2.1 GPX Formát GPX byl vyvinut pro výměnu informací mezi počítačem a GPS zařízením. Slouží k uchovávání trasových bodů, stop (angl. track) a cest (angl. route). Stopa znázorňuje zaznamenanou cestu a cesta je seznam bodů k projití. (12)

21

4.4.2.2 GML GML je standard pro výměnu geografických dat vyvíjen konsorciem OGC. Oproti GPX, které je hlavně určeno pro komunikace počítače s GPS zařízením, podporuje více typů geometrie. Pomocí něj lze uchovávat a předávat data mezi aplikacemi. Jeho výhodou je komplexnost. (13) Plánujeme jeho využití pro službu WFS, pro poskytování informací o závadách třetím stranám. Příklady primitivních typů: body (gml:Point) křivky (gml:LineString, gml:Curve,...) polygony (gml:Polygon, gml:LinearRing, ...) 3-rozměrná tělesa (gml:Solid, ...) Komplexní typy vznikají z primitivních, dělí se na: kompozitní – vzniklé složením z jednoduchých objektů (gml:CompositeCurve, gml:CompositeSurface, ...) agregační – vzniklé sdružením více jednoduchých geometrií (gml:MultiPoint, gml:MultiCurve,…) 4.4.2.3 KML KML je určen pro publikaci geografických dat (bod, linie, plocha, polygon, aj.). Byl vyvinut firmou Keyhole, Inc jako API pro aplikaci Earth Viewer (později přejmenována na Google Earth). Prvky využívají pro lokalizaci souřadnicový systém WGS84 a nepovinnou výškou nad mořem podle vztažného systému EGM96. (14) V KML jde ukládat geometrie, ale oproti GML je zaměřeno na zobrazování dat. Poskytuje značky pro nastavení úhlu pohledu na bod, způsob vykreslovaní aj. Tyto značky jsou využity pro aplikaci Google Earth. Od roku 2008 se stal standardem OGC. Stává se důležitým formátem pro zobrazování geografických dat nejen na webu, ale i v mobilních zařízeních a desktopových aplikacích. Mezi výhody patří: možnost přidání fotografií a popisu k bodům a oblastem, podporuje zobrazení 3D objektů, široká podpora stylů vzhledu. Mezi nevýhody patří: Nehodí se pro zaznamenání tras, nedokáže k linii bodů vkládat čas. Google Earth Dříve známý jako Earth Viewer je aplikace pro prohlížení mapových podkladů. Lze v něm zobrazovat vrstvy bodů a fotek. Slouží jako editor pro soubory KML a KMZ. Místo zobrazování dat na mapě můžeme uživateli generovat KML soubor, který si následně otevře v tomto programu. (15)

22

KMZ Jde o rozšíření formátu KML. KMZ je ZIP archív s koncovkou kmz. Obsahuje kořenový KML soubor doc.kml a ve složce files připojené soubory (JPEG, GIF, aj.). Jelikož jde o ZIP archív, můžeme ho automaticky generovat. (14)

4.4.3 Zobrazení dat na mapě 4.4.3.1 Srovnání dostupných mapových API Existuje více způsobů, jak zobrazit poziční data na mapě. Můžeme zobrazovat mapové podklady šířené pomocí protokolu WMS, využít dostupné API mapových portál nebo nabídnout uživatelovi soubor, který si dále zobrazí v aplikaci pro prohlížení map (např. GoogleEarth). Snažím se ukázat různé možnosti a následně vybrat nejvhodnější řešení. Amapy.cz Mezi výhody patří: dobré API se spoustou ukázek, možnost vlastních mapových podkladů. Mezi nevýhody patří: horší mapové podklady mimo ČR a SR, nepodporuje geocoding. Licenční podmínky: rozděluje využití na komerční a nekomerční, ale zároveň říká, že v případě, že společnost Atlas posoudí užití API jako komerční, je oprávněn udělit souhlas s takovým užitím nebo takové užití zakázat a zastavit, veřejný a bezplatný přístup na internetové stránky aplikace, musí být uveden odkaz na http://amapy.atlas.cz, aplikace nesmí fungovat jako součást jiné aplikace poskytované za úplatu či jiné protiplnění. (16) Google maps Mezi výhody patří: dobře zdokumentované API, možnost vyzkoušení na takzvaném hřišti (17), podpora formátů geoRSS a KML, podpora technologie Flash, více mapových vrstev (např. měsíc, mars a mapa oblohy), podpora geocoding, dostupné hotové JavaScriptové knihovny rozšiřující funkcionalitu API. Mezi nevýhody patří: počet požadavků na službu geocoding je limitován na 15 000 během 24 hodin.

23

Licenční podmínky zakázáno překrývat nebo odstraňovat mapový podklad obsahující logo Googlu, zakázáno používat API pro sledování pohybu vozidel nebo osob v reálném čase s daty získanými z geopozičních systémů, veřejný a bezplatný přístup k internetové stránce aplikace používající Google Maps API. Google Maps API Premier Kromě veřejných bezplatných API Google nabízí placené Google Premier API. Služba rozšiřuje nabídku Google Maps API o protokol http a větší datový provoz pro používání map a služby geocoding. Při uzavření smlouvy získáte licenční podmínky, opravňující k provozu i na komerčních službách. To znamená, pokud chceme provozovat mapy v komerční aplikaci, například přímo v IS SilniceNet, musíme Googlu platit roční poplatek. (18) Map24 Licenční podmínky zakazuje zobrazení pozice a pohybu osob, vozidel a dalších objektů s použitím polohy získané z geopozičních zařízení, použití je omezeno na 10 000 transakcí během 24 hodin na jeden aplikační klíč; za transakci se považuje (nejen) každý požadavek na geocoding nebo vyhledání trasy, přístup k internetové stránce aplikace musí být veřejný a bezplatný, ale umožňuje komerční i nekomerční využití. (19) Mapy.cz Mezi výhody patří: další mapové vrstvy, například turistické a cykloturistické. Mezi nevýhody patří: mezený denní počet zobrazení (v současné době 1000 denně), horší mapové podklady mimo ČR a SR. Licenční podmínky: Lze využít pouze i pro nekomerční provoz. (20) Yahoo maps Mezi výhody patří: Možnost vytvoření výřez mapy ve formátu PNG dle kritérií, podpora vyhledávání v kolekcích společnosti Yahoo, podpora dopravních informací. Licenční podmínky: Použití omezuje na 50 000 transakcí během 24 hodin na jednu IP adresu,

24

zákaz zobrazování polohy a pohybu osob, vozidel a dalších objektů omezuje na data získaná z geopozičních zařízení mladší 6 hodin, zakazuje využití dat získaných z dotazů na geocoding jiným způsobem než použitím v mapových produktech Yahoo, striktně omezuje použití pouze pro osobní účely. (21) Bing maps Mezi výhody patří: dobrá dokumentace. Mezi nevýhody patří: horší mapové podklady mimo ČR a SR. Licenční podmínky: použití omezuje na 50 000 požadavků na geocoding během 24 hodin a 250 současně zobrazených bodů zájmu, službu dělí na komerční a nekomerční provoz, je zakázáno zobrazovat data o poloze nebo pohybu s použitím dat získaných z geopozičních zařízení. (22) 4.4.3.2 Web Map Service WMS (Web Map Servis) v překladu znamená webová mapová služba. Je vyvíjena a dále šířena konsorciem OGC. Jde o standard služby pro sdílení mapových podkladů v prostředí internetu. OGC standard na WMS definuje 3 základní operace, ke kterým se přistupuje pomocí parametru REQUEST v URL adrese: GetCapabilities – odpoví XML souborem obsahující informace o poskytované službě, názvy dostupných vrstev a možné souřadnicové formáty. GetMap – vrátí mapu dle zadaných parametrů. GetFeatureInfo – vrátí XML soubor s atributy požadovaného prvku na mapě. Geoinformační data bývají jedny z nejdražších dat. Služba umožňuje distribuci tematických geografických informací. Výsledkem požadavku je primárně nejrůznější obrazový formát (JPEG, PNG, aj.). Obrazová data jsou georeferencována (vztažena k souřadnicovému systému). Mohou vzniknout složením více mapových vrstev. (23) Služba WMS se uplatněním trochu liší od výše zmíněných API mapových portálů. Je cílena více na společnosti pracující s geografickými daty, než na pouhé zobrazování map na webových stránkách. Technická odlišnost je ve způsobu zobrazování dat, není tak přímočaré, jak v API mapových portálů. Výhodou WMS jsou licenční podmínky některých poskytovatelů služby. Například prostřednictvím služby ČÚZK poskytuje v souladu se zákonem č. 106/1999 Sb., o svobodném přístupu k informacím, bezplatný přístup ke grafickým datům katastru nemovitostí.

25

4.4.3.3 Zvolené řešení Jsou dva základní způsoby získávání mapových podkladů v prostředí internetu. Buď použijeme API mapového portálu, nebo zvolíme službu WMS. Při srovnávání rychlosti odezvy při prohlížení dat z mapového portálu Google a WMS služby poskytované ministerstvem životního prostředí, odezva WMS služby byla pomalá, až nedostatečná. Tato závada se ukázala být hlavní nevýhodou řešení využívající WMS. Bohužel tyto mapové podklady nesplňují požadavky normy WMS na rychlost odezvy. Kvalita podkladů je podobná. Implementace Google maps API bývá snazší, ale služba WMS nám nabízí více možností. Pro zobrazování dat jsem zvolil službu WMS a data poskytované ministerstvem životního řešení. Nabízí přes padesát mapových vrstev, které přes sebe můžeme skládat a vytvářet tím mapu. Výhodou je cena řešení, WMS je poskytováno zdarma. Za používání API v komerčních aplikacích je nutné platit poplatky. Mapu vykresluji pomocí javascriptové knihovny Openlayers. Její použití se neliší od mnohých API mapových portálu.

4.5 Výstup do zařízení GPS Pro výstup do zařízení GPS uživatelovi systém nabízí soubor GPX nebo KML. Pokud uživatel vlastní GPS zařízení značky Garmin, přímo ze systému mu umožníme nahrát data do jeho zařízení pomocí Garmin Communicator Pluginu.

4.6 Výstup do souborů Uživatele stojí mnoho práce vkládáni dat do systému. Proto je vhodné poskytnout možnost snadno získat data ze systému zpět. Systém bude umožňovat zobrazovat závady na mapě, výstup ve formátu GPX pro GPS zařízení, KML pro aplikaci Google Earth a pro GPS zařízení, XLS a DOC.

4.6.1 Výstup do formátu XSL a DOC Uživatelé systému vlastní kancelářský balík MS Office 2000 a novější. Proto jsem pro výstup zvolil možnost generovat speciální HTML soubory, které mají navíc značky pro úpravu vzhledu dokumentu. Značky jsou specifikovány firmou Microsoft. Generované dokumenty vypadají pěkně, obsahují záhlaví, zápatí a číslo stran. Do dokumentu lze vložit i obrázky. Přidáme je zakódované funkcí base64 do souboru za HTML značky. Jde o velmi jednoduchý způsob, který není náročný na výpočetní zdroje. Jeho velkou nevýhodou je nekompatibilita s jinými kancelářskými balíky.

4.7 Práce se systémem Systém zahrnuje stránku pro filtrování, editaci, tisk záznamů, nastavení programu, správa uživatelů a oprávnění aj. Rozeberu nejpoužívanější stránky a na diagramu zobrazím základní navigaci systémem. V přílohách jsou uloženy obrazovky webového rozhraní. Pro práci se systémem se uživatel musí přihlásit. Následuje úvodní obrazovka, na které zvolí, jestli chce prohlížet závady nebo vkládat.

4.7.1 Úvodní obrazovka Každá uživatelská role má v systému jiné cíle. Je důležité uživatelovi nabídnout jen to, co ho zajímá. Proto tato obrazovka se pro každou roli liší. Kontrola potřebuje založit nebo pokračovat v prohlídce. Údržba potřebuje vědět, co je potřeba opravit a co již bylo opraveno. Správce zajímá, jaké závady se vyskytuji na jeho silnicích.

26

4.7.2 Pasport Na obrazovce pasportu je zobrazen seznam závad. Po kliknutí na záznam se zobrazí editační formulář záznamu. Uživatel buď používá přednastavenou sestavu prohlížení, nebo si může vytvořit vlastní, upravit jaké sloupce z tabulky závady budou zobrazeny a podle nich filtrovat a řadit záznamy. Klademe důraz na aktivní práci s daty, a ne jen vkládání dat bez možnosti vyhledávání a exportu. Datové pole v tabulce závady jsou rozděleny a podle toho lze nad nimi vyhledávat: Textové pole – pokud sloupec je formátu VARCHAR, lze nad ním vyhledávat: o přesnou hodnotu zadáním výrazu (hodnota), o negaci hodnoty napsáním „!“ před výraz (!hodnota), o přibližnou hodnotu, použijeme zástupný znak „_“ pro nahrazení znaku za jeden jakýkoliv znak (hodnot_), nebo „%“ pro nahrazení za libovolné množství libovolných znaků (hod%). Číslo nebo datum – nad záznamy typu DOUBLE, FLOAT, INTEGER a DATE lze provádět stejné vyhledávací operace: o Rovná se (12.56), o menší než (<12; <2010-10-12), o větší než (>15.5), o mimo hodnotu (!123.4), o v intervalu hodnot (2008<<2011), o mimo interval hodnot (!2008<<2009). Číselník – nad sloupcem s číselníkovými hodnotami lze vybrat jednu, nebo více hodnost, podle kterých bude záznam hledán.

4.7.3 Tiskové sestavy Na stránce je výběr výstupů dat ze systému. Základní typy výstupů jsou popsány níže: Otisk obrazovky – export vyfiltrovaných dat na stránce pasportu do formátu XLS. Protokoly závad – vytvoření protokolů o vyfiltrovaných závadách do formátu DOC. Volitelně lze tisknout i s obrazovou částí. Okruh – seznam závad – na každou stránku ve formátu DOC je vytištěna tabulka se seznamem závad z jednotlivých okruhů. Volitelně lze tisknout i s obrazovou částí. Kontroly silnic z vybraného předchozí prohlídky – tabulka závad z vybrané prohlídky ve formátu DOC. Volitelně lze tisknout i s obrazovou částí. Zobrazení závad na mapě – vytvoření KML souboru, který je následně zobrazen na mapě.

4.7.4 Editační formulář Při otevření okna každý s oprávněním může prohlížet záznam. Před editací je nutné nejdříve převzít zodpovědnost za závadu. Editační formulář se dělí se na pět uskupení editačních polí podle podobnosti dat a určení. 4.7.4.1 Umístění Kontrola uvádí popis místa, pro následné snadné nalezení závady údržbou. Hodnota čísla silnice je vybírána z číselníku náležících dané prohlídce. Hodnota úseku je číselník hodnot náležících silnici a prohlídce. Další hodnota je popis místa, zeměpisná šířka a délka.

27

Pokud uživatel vyplní GPS souřadnice, lze závadu zobrazit na mapě. Pokud vyplní pouze číslo úseku, lze zobrazit přibližné umístění závady na základě znalosti okrajových bodů úseku (tyto údaje byly importovány ze Silniční databanky Ostrava). Pro upřesnění polohy byly použity data ze Silniční databanky Ostrava. Silniční databanka Ostrava je specializované pracoviště ŘSD ČR spadající pod úsek informatiky. Působí ve 3 odděleních – Sběru dat, GIS a zpracování dat a Národního dopravního informačního a řídicího centra. Zabezpečuje provoz Informačního systému o silniční a dálniční síti České Republiky (dále jen ISSDS ČR) na sledovaných komunikacích. (24) 4.7.4.2 Popis závady Údaje edituje kontrola. Na základě popisu závady a závažnosti správce nebo údržba rozhoduje další postup opravy závady. 4.7.4.3 Návrh opatření Jde o volitelné údaje, kterými kontrola může pomoci při opravování závady. Jde o údaj návrh opatření a okamžité opatření. 4.7.4.4 Zápis majitele Údaje může editovat pouze pověřený správce. Výjimkou je hodnota kdo provede, kterou může měnit i kontrola. Editační pole obsahuje hodnoty: pokyn majitele, kdo provede, poznámka majitele, kdy provede a pokyn opravujícímu. 4.7.4.5 Zápis o odstranění Údaje edituje ten, který opravil závadu. Může to být buď údržba, nebo kontrola, která opravila závadu při své prohlídce. Editační pole obsahuje hodnoty: závadu odstranil, datum odstranění, poznámka odstranění.

28

Obrázek 12: Základní obrazovky systému a navigace mezi nimi

29

5. Závěr 5.1 Testovací provoz Momentálně je systém zkušebně používán v okrese Ústí nad Orlicí firmou JAST s. r. o. a v okrese Svitavy firmou SAM. Bohužel zatím je systém používaný pouze pro evidenci závad. Následně uživatelé data vyexportují do formátu XLS a posílají na pověřená místa ŘSD ČR. IS pomáhá automatizovat vytváření XLS dokumentů, ale původní myšlenkou je propojit kontrolu, údržbu a správu jedním systémem a omezit čas strávený dorozumíváním se. Zamezit nedorozumění, které se stávají. Jasně označit subjekt, který bude závadu opravovat. Zamezit situacím, kdy k opravě přijede více firem, tím šetřit peníze zúčastněných.

5.2 Vize Momentálně je systém navržen pouze pro evidenci a komunikaci mezi pověřenýma osobami. Bylo by užitečné navrhnout finanční modul, který by umožňoval zaznamenávat náklady na opravu silnic a vyhodnocovat výhodnost oprav oproti znovupostavení. Modul by umožňoval udržovat přehled v nákladech údržby a náklady následně účtovat správě.

30

Jmenný rejstřík Geocoding ..................................................................... 20 Geonames ................................................................. 20 HTML 5 ........................................................................ 19 JavaScript Garmin Communicator Plugin API .......................... 17 Greybox .................................................................... 18 Openlayers................................................................ 18 KML KMZ ......................................................................... 22 Legislativa ....................................................................... 3 Mapa ............................................................................. 22 Amapy ...................................................................... 22 Google maps ............................................................. 23 Google Maps API Premier................................... 23 map24 ....................................................................... 23 mapy.cz .................................................................... 24 Windows live maps .................................................. 24 WMS ........................................................................ 25 Yahoo maps .............................................................. 24 MS Office ...................................................................... 26 DOC ......................................................................... 26

XSL .......................................................................... 26 PHP ............................................................................... 16 Prohlídka silnic Běžné prohlídka ......................................................... 3 Hlavní prohlídka......................................................... 4 Mimořádné prohlídka ................................................. 4 Závada ........................................................................ 4 SQL MySQL .................................................................... 17 MySQL Workbench ............................................ 17 SÚS ................................................................................. 3 Uživatelské role .............................................................. 6 Administrátor ............................................................. 9 Kontrola ................................................................. 3, 8 Správa .................................................................... 3, 8 Údržba .................................................................... 3, 9 XML ....................................................................... 17, 21 GML......................................................................... 21 GPX ......................................................................... 21 KML......................................................................... 22

Seznam obrázků Obrázek 1: Aktor ............................................................................................................................... 6 Obrázek 2: Vazba „include“ .............................................................................................................. 6 Obrázek 3: Případ užití...................................................................................................................... 7 Obrázek 4: Vazba asociace ............................................................................................................... 7 Obrázek 5: Diagram případu užití ..................................................................................................... 7 Obrázek 6 Scénář práce se systémem uživatele v roli správa ........................................................... 8 Obrázek 7: Scénář práce se systémem uživatele v roli správa .......................................................... 9 Obrázek 8: Scénář práce se systémem uživatele v roli údržba .......................................................... 9 Obrázek 9: Stavový diagram ........................................................................................................... 11 Obrázek 10: ERD diagram .............................................................................................................. 12 Obrázek 11: Způsob automatického získávání čísla úseku a silnice ............................................... 21 Obrázek 12: Základní obrazovky systému a navigace mezi nimi ................................................... 29

31

Citovaná literatura 1. Zákon 13/1997 Parlamentu České republiky o pozemních komunikacích. 2. Vyhláška č. 104/1997 Sb. (prováděcí vyhláška k Zákonu o pozemních komunikacích). 3. MySQL. Wikipedia. [Online] [Citace: 20. 04 2010.] http://en.wikipedia.org/wiki/MySQL. 4. MySQL Workbench. MySQL Workbench. [Online] [Citace: 12. 04 2010.] http://wb.mysql.com/. 5. ZEND DEVELOPER ZONE. XML in PHP 5 - What's New? [Online] [Citace: 12. 03 2010.] http://devzone.zend.com/node/view/id/1713. 6. Garmin Communicator Plugin API. Garmin Developer. [Online] [Citace: 10. 03 2010.] http://developer.garmin.com/web-device/garmin-communicator-plugin/. 7. OpenLayers: Home. OpenLayers. [Online] [Citace: 12. 04 2010.] http://openlayers.org/. 8. Orangoo Labs - GreyBox. Orangoo Labs - GreyBox. [Online] [Citace: 10. 03 2010.] http://orangoo.com/labs/GreyBox/. 9. W3C. Geolocation API Specification. [Online] [Citace: http://www.w3.org/TR/2008/WD-geolocation-API-20081222/#introduction .

20.

04

2010.]

10. You Are Here (And So Is Everybody Else). Dive into HTML 5. [Online] [Citace: 13. 04 2010.] http://diveintohtml5.org/geolocation.html. 11. Locify. Locify. [Online] [Citace: 12. 12 2009.] http://www.locify.com/. 12. GPX: the GPS Exchange http://www.topografix.com/gpx.asp.

Format.

GPX.

[Online]

[Citace:

10.

03

2010.]

13. Wikipedia. Geography Markup Language. [Online] http://en.wikipedia.org/wiki/Geography_Markup_Language.

[Citace:

14.

03

2010.]

14. KML. Google Code. [Online] [Citace: 12. 01 2010.] http://code.google.com/intl/csCZ/apis/kml/. 15. Google Earth. Wikipedia. http://en.wikipedia.org/wiki/Google_Earth.

[Online]

[Citace:

12.

10

2009.]

16. AMapy API. Úvod | AMapy API. [Online] [Citace: 12. 11 2009.] http://amapy.centrum.cz/apidoc/. 17. Google Code Playground. Google Code Playground. [Online] [Citace: 12. 03 2010.] http://code.google.com/apis/ajax/playground/. 18. Google maps API. Google maps http://code.google.com/intl/cs-CZ/apis/maps/.

API.

[Online]

19. MapTP AJAX API 2.3 . http://www.nn4d.com/site/global/build/manuals/ajaxapiintroduction.jsp.

[Citace:

10.

Navteq.

03

2010.]

[Online]

32

20. API Mapy.cz. API Mapy.cz. [Online] [Citace: 12. 02 2010.] http://api.mapy.cz/. 21. Yahoo! Maps Web Services - The Yahoo! Maps Developer APIs. Yahoo! Maps Web Services. [Online] [Citace: 12. 02 2010.] http://developer.yahoo.com/maps/. 22. BING MAPS PLATFORM - Developer Resources, Online Map APIs, SDKs, and Map Web Services. BING MAPS PLATFORM . [Online] [Citace: 15. 04 2010.] http://www.microsoft.com/maps/developers/. 23. Beaujardiere, Jeff de la. OpenGIS® Web Map Server Implementation Specification. [Online] 15. 03 2006. OGC® 06-042. 24. Silniční databanka Ostrava. Ředitelství silnic a dálnic ČR. [Online] [Citace: 29. 03 2010.] http://www.rsd.cz/Silnicni-a-dalnicni-sit/Silnicni-databanka-Ostrava.

33