Úvod

Web Map Service (WMS) v překladu znamená webová mapová služba. Jedná se poměrně o mladou normu pro šíření geografických informací ve formě map. Tyto mapy jsou prezentovány jako obrazová data (rastr). První verze WMS byla vyvinuta Open Geospatial Consortium (OGC) kolem roku 2000. Jde o jeden z nejrozšířenějších standardů tohoto konsorcia, který byl především původně určen jako jeden z nástrojů GIS.

Mojí motivací k návrhu předmětu této práce "Webový portál o mapových službách" bylo to, že při prostudování témat bakalářských prací vypsaných katedrami oboru geodézie a kartografie mě zaujalo téma WMS Ing. Soukupa. Při průzkumu toho, co tato služba vlastně je, narazil jsem na problém v nedostatku informací na internetu. Po zjištění co WMS zamená, chtěl jsem si prakticky vyzkoušet fungování této služby. Objevil se ovšem další problém, spočívající v tom, že jsem nemohl najít WMS server, který bych si připojil do WMS prohlížeče.

Tak vzniknul nápad na vytvoření tohoto vyhledávacího portálu mezi WMS servery, který by obsahoval přehled WMS serverů území ČR, popř. SR. Zároveň součástí portálu by byla informační část popisující WMS, její použití, využití a základní principy.

Využití takového portálu by mohlo být všestranné, protože informace o WMS v českém jazyce na internetu sice jsou, ale nejsou ucelené. Komplexní seznam WMS serverů na našem území neexistuje a vyhledávací služba v metadatech WMS serverů existuje jen jedna [44] , a to v takové podobě, že nevyužívá všech možností těchto dat o datech (metadat). Portál by mohly využívat krajské úřady (jejich GIS oddělení), ČUZK, privátní sektor využívající možností WMS a další instituce a subjekty.

Takový portál by měl využívat nejnovější informační standardy pro web, jakými jsou XHTML 1.1 a CSS 2. Zároveň, aby portál fungoval jako databáze + program, měl by podporovat např. PHP a MySQL.

Stanovené cíle této práce jsou dosti obsáhlé. Již při zadání práce jsem se proto dohodl s vedoucím práce, že využiji výsledky bakalářské práce mého spolužáka Jana Říhy, který se také zabývá WMS, ale s ohledem na průzkum datových zdrojů. Výsledky jeho práce budou tudíž využity v informační sekci webového portálu.

[Úvod]
[Obsah]

Vymezení pojmů

Pojmy

Zkratky

Význam typografického značení

[Vymezení pojmů]
[Obsah]

Kapitola 1

Web Map Service

S rozvojem geografických informačních systému (GIS) bylo zapotřebí vyvinout standardy, jenž by tyto složité systémy byly schopny společně využít. Další snahou bylo zamezit problému s nepřenositelností a uzavřeností formátů pro ukládání GIS dat. Dříve si každá GIS softwarová firma vyvinula vlastní formát, který byl často uzavřený (nepřístupný pro ostatní firmy).

Tuto situaci se snaží vyřešit Open Geospatial Consortium (OGC) [7] , které se dříve jmenovalo Open GIS Consortium. Skládá se z mnoha členů GIS komunity (tvůrců softwaru, předních vědců, atd.). Jeho cílem je sjednotit pomocí mezinárodní norem formáty pro různé typy dat pro GIS pro jejich zjednodušené předávání na národních i mezinárodní úrovni při používání nestejných softwarů. Jeho vytvořeným standardem je právě Web Map Service (WMS) [59] . Příkladem toho, že WMS je jeden z nejpopulárnějších standardů vyvinutých OGC je tabulka č. 1.1.

Poznámka: výraz v uvozovkách znamená vyhledání celého sousloví

[Kapitola 1]
[Obsah]

1.1 Úvod do WMS

Web Map Service je to webová mapová služba, která byla vytvořena z důvodu umožnění sdílení dat GIS v distribuovaném prostředí Internetu. Jedná se o nástroj nejen pro GIS systémy, který zpřístupňuje informace ve formě map (rastrů). Výsledkem požadavku např. GIS softwaru na WMS server jsou primárně obrazová data v nejrůznějších formátech (JPEG, TIFF, PNG, aj.), které zobrazují tematické geografické informace (tematickou mapu - vrstvu). Tato obrazová data mohou být výsledkem překrytu více vrstev (mapová kompozice). To, že je georeferencován (vztažen k souřadnicovému systému), nám poté umožní jeho správnou prezentaci. Georeferencování v tomto případě můžeme chápat jako jednoznačně daný referenční souřadnicový systém a souřadnicový obdélník (box) v tomto systému, jenž obaluje obrazová data výsledku.

[Kapitola 1]   [1.1 Úvod do WMS]
[Obsah]

1.2 Historie vývoje WMS

První oficiální dokument popisu WMS verze 1.0.0 vydalo OGC dne 19. května 2000. V současné době je nejrozšířenější používání verze 1.1.1 z roku 2002. Přehled vývojových verzí uvádí tabulka č. 1.2. Protože OGC je jen tvůrcem, správcem a inovátorem tohoto standardu, tak není organizací, jenž by ho prohlásila za normu. Jako mezinárodní norma byl WMS přijat úřadem International Organization for Standardization (ISO) pod označením ISO 19128 Geographic Information: Web Map Service v roce 2005.

Poznámka: data zjištěné z oficiálního webového portálu OGC [7]
                Druhy typu dokumentů:
                D-RP - Deprecated Recommendation Paper (neschválené doporučení)
                D-IS - Deprecated Implementation Specification (neschválené provedení specifikace)

[Kapitola 1]   [1.2 Historie vývoje WMS]
[Obsah]

1.3 Princip WMS

Základním principem WMS jsou vzájemné interakce, a to stroj-stroj a stroj-člověk. V nejvyšším vrcholu této komunikace je mapový server. Pokud podporuje WMS, můžeme hovořit o WMS serveru. V jeho úložišti jsou uskladněny georeferencovaná obrazová data (GeoTIFF), v nastavení jsou popsány možnosti WMS serveru a v databázi jsou uloženy atributové informace o geografických objektech (objekty u nichž je známa poloha v souřadnicovém referenčním systému a déle k nim existují atributy). Nejčastěji se pro označení souřadnicového referenčního systému (CRS - Coordinate Reference Systém) využívá dataset EPSG [2] (podrobněji je popsán v příloze E).

Klient je potom software, který komunikuje se serverem za účelem získání informací. K této komunikaci využívá Hyper Text Transfer Protocol (HTTP), resp. jeho metody dotazů, jimiž jsou GET a POST (více v kapitole 2.2.1 a 2.2.2). Klient si poté zpracuje informace, které mu server zpřístupnil.

Tyto informace pomocí definovaného uživatelského rozhraní zpřístupní uživateli. Jedná se o interakci člověk-stroj (resp. uživatel-klient) názornější vysvětlení naznačuje obrázek 1.

Obrázek 1 - Princip interakce WMS (člověk - stroj - stroj)

[Kapitola 1]   [1.3 Princip WMS]
[Obsah]

1.4 Klady a zápory webové mapové služby

Webová mapová služba (WMS) se dá popsat z hledisek jejich kladných a záporných vlastností [19] jak pro uživatele, klienta, apod.

Klady:

• uživatel si může připojit jen ta data (vrstvu), která skutečně potřebuje
• uživatel není závislý na typu mapového serveru a operačním systému, na němž tento server funguje (je softwarově nezávislý)
• po připojení serveru je možno zjistit jeho aktuální možnosti (metadata)
• výhodou pro vlastníky, popř. správce dat je to, že výsledkem dotazu jsou informace, které jsou šířeny prostřednictvím obrazových dat, čímž se snižuje riziko zneužití
• uživatel může k těmto datům přistupovat pomocí nejrůznějších hardwarových prostředků, které mají přístup k internetu:
  • osobní počítač (existuje nepřeberné množství aplikací),
  • kapesní počítač (nyní už existuje několik aplikací, které WMS podporují),
  • mobilní telefony (podpora WMS není zatím známá, avšak technologie mobilních telefonů a kapesních počítačů v poslední době splývá),
  • GPS navigační systémy s podporou WMS (například integrované do osobního automobilu),
  • totální stanice s podporou WMS (s dostatečným grafickým rozlišením),
  • a další.
• data jsou skladována na jednom místě, a to obvykle u správce těchto dat, tudíž je zaručena jejich aktuálnost a dále odborná správa
• další výhodou pro vlastníky, popř. správce dat je to, že přístup k poskytovaným datům mohou zpoplatnit, a to buď paušálně nebo pomocí mikroplateb (přístup je pro běžné uživatele omezen)
• pro zobrazení dat postačuje jednoduchá aplikace na straně klienta, např. tenký klient ve formě webové aplikace
• pomocí jednotného standardu je možné připojit nejrůznější data z různých serverů
• data mohou být na serveru uložena v nejrůznějších formátech, navenek jsou prezentovány jen v přípustných formátech
• server může využívat dat jiných serverů, jedná se o tzv. kaskádování serverů
• WMS je navržena tak, aby podporovala nejrůznější souřadnicové systémy, které se vyskytují na Zemi, a to prostřednictvím EPSG seznamu (viz. příloha E).

Obrázek 2 - Princip tzv. kaskádování WMS serverů

Zápory:

• hardware musí mít přístup k internetu (LAN, WI-FI, GPRS, aj.)
• při nízké rychlosti připojení k internetu dochází k pomalému načítání obrazových dat (vše je pak dále závislé ještě na počtu připojených vrstev)
• některé typy mapových serverů (WMS serverů) se plně neřídí specifikacemi OGC, proto může nastat chyba při pokusu připojit službu do určitého klienta (tenký, tlustý)
• klient získá jen obrazová data, nemůže na nich bez předchozí vektorizace provádět analýzy, výběry, atd.

[Kapitola 1]   [1.4 Klady a zápory webové mapové služby]
[Obsah]

1.5 Obdobné služby

Webová mapová služba není jediná služba, která prostřednictvím internetu umožňuje přístup ke geografickým datům (mapovým produktům). OGC spravuje i další obdobné formáty. Jsou jimi například Web Feature Service (WFS), Web Coverage Service (WCS), aj. Každá z těchto služeb je určena ke specifickému účelu šíření prostorových dat.

Je-li WMS určeno k šíření mapových produktů prostřednictvím obrazových dat ve standardních formátech jako jsou např. JPEG, PNG, BMP, TIFF aj., tak potom ostatní služby budou využívat jiné formáty k popisu geografických dat.

Služba Web Feature Service by ve volném překladu znamenala webová hlavní služba. Správcem tohoto formátu je opět OGC. Hlavní výhodou této služby je to, že nám vrátí neobrazová vektorová geografická data, jež narozdíl od WMS mají své přednosti. Po jejich načtení můžeme data upravovat a analyzovat. K šíření vektorových dat se využívá aplikace XML, a to formát Geography Markup Language (GML) [6] .

[Kapitola 1]   [1.5 Obdobné služby]
[Obsah]

1.6 Softwarové zajištění

Pod pojmem webová služba rozumíme vzájemnou interakci stroj - stroj. Jedná se o dva stroje (PC, PDA, mobilní telefon, aj.), které nezávisle na svém hardwaru umožňují vzájemnou komunikaci, prostřednictvím určitého standardizovaného protokolu. Takovým příkladem může být protokol HTTP, který je nezávislý na hardware. Webová mapová služba je potom specifickou aplikací interakce stroj - stroj. Člověk přistupuje k datům, jež jsou poskytovány pomocí WMS v interakci člověk - stroj pomocí klienta. Dle náročnosti lze tyto klienty rozdělit na dvě kategorie, a to tenký a tlustý klient.

[Kapitola 1]   [1.6 Softwarové zajištění]
[Obsah]

1.6.1 Tenký klient

Jedná se o nejjednodušší typ klienta. Jde o princip, kdy se prakticky vše zpracovává na straně serveru. Aplikace na straně klienta je omezena pouze možnostmi webového rozhraní (nejčastější případ), které se stará o zobrazování dat spravovaných serverem. Nevýhodou tohoto rozhraní je potom jednostranná zátěž serveru, čímž se snižuje odezva serveru. Nedá se tudíž ovlivnit výkonem hardwaru na straně klienta. Jeden z největších záporů se potom nalézá ve velké paletě uživatelských rozhraní (webové prohlížeče s jejich pluginy), které mohou špatně interpretovat prostředky klienta, popřípadně ho nemusí podporovat vůbec. Nespornou výhodou tenkého klienta je snadný přístup bez ohledu na hardware a operační systém.

Poznámka: informace zjištěné vlastním průzkumem

Obrázek 3 - Tenký klient společnosti HS RS s.r.o.

[Kapitola 1]   [1.6 Softwarové zajištění]   [1.6.1 Tenký klient]
[Obsah]

1.6.2 Tlustý klient

Ze znalosti pojmu tenký klient je snadné odvodit, co tlustý klient představuje. Jedná se především o aplikaci, jež běží na straně hardwaru klienta. Tato aplikace je omezena možnostmi operačního systému a použitým hardwarem. Vlastní klient pracuje na straně uživatele. Komunikuje s mapovým serverem a získává tak z něho potřebná data. Tento program může pracovat ve dvou režimech, buď online (možnost získávat nová data), nebo offline (pracuje jen s načtenými daty ze stavu online). Velikou a nespornou nevýhodou tohoto klienta je jeho závislost na operačním systému. Tento problém vyřeší jen vytvoření dalších verzí pro jiné operační systémy.

Příkladem tlustých klientů je ArcGis 8.3 (s podporou WMS), Kokeš 7.60, Google Earth, Gaia, a spousta dalších.

Obrázek 4 - Tlustý klient Gaia 3.0

[Kapitola 1]   [1.6 Softwarové zajištění]   [1.6.2 Tlustý klient]
[Obsah]

1.6.3 Mapový server

Mapový server je software pracující na architektuře klient-server (stroj-stroj). Obsluhuje a zpracovává geografická data v nejrůznějších formátech. S určitou nadsázkou by se dalo říci, že se jedná o geografický informační systém, který je ovládán pouze pomocí definovaných parametrů (není interaktivní). Spolupracuje s některým z mnoha typů webových serverů (např. Apache), který jim předá potřebné parametry z webového formuláře. Ty jsou zpracovány a zpět je vrácen buď soubor s mapou anebo výsledek dotazu.

Existuje nepřeberné množství mapových serverů. Jsou jimi jak komerční (např. od firmy ESRI) a servery jsou uvolněné pod svobodnou licencí. Mezi jeden z nejznámějších se dá zařadit MapServer [60] univerzity v Minnesotě v licenci GNU GPL.

Tak jako HTTP server např. Apache podporuje nejrůznější moduly PHP, IMAP, aj., tak i mapový server podporuje nadstavby, jimiž je například podpora WMS někdy označovaná jako WMS server.

Obrázek 5 - Princip fungování mapového serveru, zdroj [47]

[Kapitola 1]   [1.6 Softwarové zajištění]   [1.6.3 Mapový server]
[Obsah]

1.7 A co budoucnost?

Jak už bylo zmíněno, nejrozšířenější verzí je 1.1.1. Úspěch této verze souvisí hlavně s implementací WMS standardu do nejdůležitějších mapových serverů, jimiž je např. Mapserver z Univerzity Minesotta. Tato verze narozdíl od svých předchůdců umožňuje šířit i nejrůznější metadata o mapovém serveru. Verze 1.3.0, jenž je zatím neschváleným doporučením, není doposud (ke dni 28. 4. 2007) podporována žádným serverem, i když jsou náznaky, že v průběhu měsíce června roku 2007 bude již implementována do Mapserveru univerzity v Minesottě.

Snahou vývojářů standardu WMS je i rozšiřovat možnosti webové mapové služby a přizpůsobovat ji nejnovějším informačním formátům (XML, XSD, URL, aj.). Takovým příkladem může být dokument OGC 02-017r1 konsorcia OGC s názvem Web Map Service Implementation Specification Part 2: XML for Requests using HTTP POST. Jeho snahou je rozšířit zaostávající podporu metody dotazu POST protokolu HTTP v XML souborech, prostřednictvím nichž komunikují server a klient (tenký nebo tlustý).

Ještě zajímavějším dokumentem je OGC 06-045r1 WMS - Proposed Animation Service Extension. Tento zkoumá možnosti rozšíření WMS o animované sekvence závislé na prostoru a času. Dokument je zpracován, aby vyhověl verzi 1.1.1. Každá vrstva může mít dle specifikace WMS 1.1.1 atributy:

Tyto atributy dané vrstvy vymezují odlišné verze z hlediska času. V tomto případě existují v dané vrstvě tři její časové varianty.

Poznámka: data zjištěné z oficiálního webového portálu OGC [7]
      Druhy typu dokumentů:
      DP - Discussion Paper (diskusní dokument)

[Kapitola 1]   [1.7 A co budoucnost?]
[Obsah]

1.8 Typy dotazů na WMS server

Klient (tenký popř. tlustý) komunikuje s mapovým serverem prostřednictvím třech základních dotazů (request), které jsou součástí query obsažené v URL. Aby si vzájemně rozuměli, byly OGC vytvořeny tři hlavní typy dotazů na mapový server. Jedná se o dotazy GetCapabilities, GetFeatureInfo a GetMap. Názvy těchto dotazů jsou platné až od verze WMS 1.1.0. V důsledku vývoje verzí webových mapových služeb se dané funkce nejmenovaly vždy stejně. Jejich vývojové názvy uvádí tabulka 1.5.

Poznámka:
      1) dále existuje dotaz Coverage, který se vyskytuje jen v této verzi
      2) dále existují dotazy GetLegendGraphic, GetStyles, PutStyles, které se vyskytují jen v této verzi
      3) dále existuje dotaz _ExtendedOperation, který se vyskytuje jen v této verzi

Vlastní specifikace služby a její aplikace do praxe můžou být rozdílné věci, což dokazuje předchozí tabulka. U některých mapových serverů byly přidány navíc ještě další typy dotazů, které již nebyly vytvořeny OGC. Tudíž nemusí být podporovány všemi mapovými servery na rozdíl od třech hlavních.

[Kapitola 1]   [1.8 Typy dotazů na WMS server]
[Obsah]

1.8.1 GetMap

Tento typ dotazu lze považovat za hlavní (primární), a to z toho důvodu, že klientovi zpřístupní mapu ve formě obrazových dat v určitém formátu. Query (parametry dotazu obsaženého v URL) URL musí obsahovat parametr, REQUEST=GetMap

Specifikace (záleží dle použité verze WMS) vyžaduje ještě další povinné parametry, které mapovému serveru sdělí podrobnější informace o části mapy jenž má zpřístupnit. Jsou jimi například souřadnicový systém, formát obrazových dat, název vrstev a stylů, souřadnicový box, aj.

Obrázek 6 - Výsledek dotazu GetMap na server

[Kapitola 1]   [1.8 Typy dotazů na WMS server]   [1.8.1 GetMap]
[Obsah]

1.8.2 GetCapabilities

Pokud daný klient nezná možnosti a vlastnosti spravovaných dat, což se skoro ve všech případech děje, musí tyto možnosti zjistit. Proto klient při první komunikaci se serverem sestaví GetCapabilities dotaz. Query musí obsahovat parametr REQUEST=GetCapabilities.

Specifikace vyžaduje ještě jeden povinný parametr SERVICE=WMS.

Po platném sestavení dotazu je zpřístupněn XML soubor popisující danou službu. Tato data jsou metadaty mapového serveru, což znamená, že obsahují veškeré potřebné informace pro komunikaci se služnou.

[Kapitola 1]   [1.8 Typy dotazů na WMS server]   [1.8.2 GetCapabilities]
[Obsah]

1.8.3 GetFeatureInfo

Tento typ dotazu vrací klientovi XML soubor s atributy daného prvku na mapě o určitých souřadnicích. Query URL musí obsahovat parametr REQUEST= GetFeatureInfo.

Specifikace (záleží dle použité verze WMS) vyžaduje ještě další povinné parametry, které mapovému serveru řeknou podrobnější informace o daném dotazu.

[Kapitola 1]   [1.8 Typy dotazů na WMS server]   [1.8.3 GetFeatureInfo]
[Obsah]

1.8.4 Chybný dotaz (query)

Za předpokladu znalosti URL platného WMS serveru můžou nastat případy, kdy dotaz sestavený klientem je pro server chybný (nesrozumitelný), nebo neúplný. V takových případech od verze 1.1.0 vrací XML soubor s popisem dané chyby (viz. tabulka 1.12). Příklad chybného dotazu uvádí tabulka 1.11.

[Kapitola 1]   [1.8 Typy dotazů na WMS server]   [1.8.4 Chybný dotaz (query)]
[Obsah]

Kapitola 2

XML soubor dotazu GetCapabilities

WMS je jako například RSS, XHTML nebo SVG aplikací XML, a to především jeho dotazy GetCapabilities a GetFeatureInfo. To znamená, že tuto aplikaci někdo vymyslel a dále vytvořil definici typu dokumentu (DTD) nebo XML schéma, aby zajistil jednotnost používání tohoto formátu. Tvůrcem, správcem a inovátorem je OGC konsorcium. Tak jako každý nápad v průběhu času, tak i tento standard prošel dlouhým vývojem, což potvrzuje počet jeho vývojových verzí.

Tento soubor je jakýmsi metadatovým souborem popisující veškeré možnosti daného serveru.

[Kapitola 2]
[Obsah]

2.1 Metadata

Název metadata pochází ze spojení z řeckého meta = mezi a latinského data = to, co je dáno. Jsou to strukturovaná data o datech.

Takovým praktickým příkladem může být fotografie pořízená digitálním fotoaparátem. Přístroj automaticky připojí skryté informace do souboru s fotografií. Tato data jsou ukládána v tzv. formátu EXIF. Jsou to například informace o typu fotoaparátu, ohniskové vzdálenosti, cloně, datu a času pořízení, expozičním času apod.

S jakýmkoliv formátem metadat se tudíž setkáváme běžně, aniž si to uvědomujeme. V knihovnách je příkladem metadat katalogizační záznam, až již v klasické lístkové podobě, nebo ve formě elektronického záznamu v automatizovaném knihovním systému.

V důsledku velkého rozvoje internetu z hlediska používání pro ukládání a zpřístupňování nejrůznějších informací nastává problém s jejich vyhledáváním. Tuto situaci usnadňují právě metadata, s jejichž pomocí se hledání a správa informací stává snazší.

Vazba mezi metadatovým záznamem a zdrojem který popisují, může být dvojí:

1) metadatový záznam je uložen samostatně a odděleně od zdroje (např. katalogizační systém záznamů v knihovně)

2) metadata jsou vnořena (embedded) přímo do samotného zdroje (např. pomocí značek u dokumentů v jazyce SGML, HTML apod.)

[Kapitola 2]   [2.1 Metadata]
[Obsah]

2.2 Přehled využívaných technologií

2.2.1 URI (Uniform Resource Identifier)

URI je zkratka odvozená z anglického jazyka Uniform Resource Identifier [14] , což v překladu znamená jedinečnou identifikaci zdroje. Skládá se z řetězce znaků, jehož formát se řídí určitými kritérii. Jedná se tudíž o množinu všech druhů adres. Obsahuje dvě složky, a to adresu objektu a schéma. Schémat v poslední době narůstá s rozvojem nových komunikačních protokolů. Jsou jimi například http, ftp, file, mailto a mnoho dalších. Každé toto schéma začíná vždy dvojtečkou a dále následuje vlastní adresa objektu. Forma této adresy je potom závislá na druhu schématu. Příkladem takového URI může být například: http://www.google.com

Do rodiny URI patří i URL (Uniform Resource Locator) a URN (Uniform Resource Name)

Obrázek 7 - Schéma vazeb mezi URI, URL a URN

[Kapitola 2]   [2.2 Přehled využívaných technologií]   [2.2.1 URI (Uniform Resource Identifier)]
[Obsah]

2.2.2 URL (Uniform Resource Locator)

URL, neboli Uniform Resource Locator [14] ve volném překladu znamená jedinečný zdrojový lokátor. Jedná se o podmnožinu URI. Skládá se z řetězce znaků s definovanou strukturou. Slouží k přesné specifikaci umístění zdrojů informací (ve smyslu dokument nebo služba) na internetu.

Příkladem takového URL může být například tato fiktivní internetová adresa: http://gama.fsv.cvut.cz:80/vyuka/tcv10.php?akce=zkousky&sem=letni

1) komunikační protokol:

http (Hyper Text Transfer Protocol)

2) adresa serveru:

gama.fsv.cvut.cz (doména 4. řádu)

3) komunikační port:

80 (pokud se neuvede tak pro HTTP je implicitně 80)

4) adresa dokumentu:

vyuka/tcv10.php (jedná se o relativní interní adresu na serveru v rámci složky určené pro web např. /public_html)

5) dotaz (query)

akce=zkousky&semestr=letni

Začátek dotazu je uvozen znakem "?". V dotazu se vyskytují dva parametry akce, jejíž hodnota je zkousky a semestr s hodnotou letni. Jednotlivé položky dotazu jsou odděleny symbolem "&".

Je možné se setkat v URL i s parametry pro HTTP autorizaci. Autorizace se skládá z uživatelského jména a k němu příslušné heslo. Příkladem může být tato fiktivní adresa http://username:password@gama.fsv.cvut.cz/

[Kapitola 2]   [2.2 Přehled využívaných technologií]   [2.2.2 URL (Uniform Resource Locator)]
[Obsah]

2.2.3 XML (EXtensible Markup Language)

EXtensible Markup Language (XML) [13] je jedním z nejdůležitějších metajazyků vyskytujících se ve světě počítačů. Byl vyvinut z metajazyka SGML. Na jeho vytvoření pracovala od roku 1996 pracovní skupina XML (XML Working Group) konsorcia World Wide Web Consortium (W3C).

Jeho výhodou oproti svému předchůdci je to, že přinesl pro programátory a správce informačních systémů dlouho očekávaný výměnný standard. Při jeho vytváření stanovili tvůrci 10 hlavních cílů tohoto metajazyka:

1. XML by mělo být přímo použitelné na internetu,
2. XML by mělo být podporováno širokou paletou aplikací,
3. XML by mělo být kompatibilní s jazykem SGML,
4. tvorba programů zpracovávající XML by měla být snadná,
5. počet volitelných částí XML by měl být naprosto minimalizován, v ideálním případě by měl být nulový,
6. dokumenty XML by měly být pro člověka snadno čitelné, dostatečně jasné,
7. návrh XML by měl být rychle hotov,
8. návrh XML by měl být metodický a stručný,
9. vytváření dokumentů XML by mělo být snadné,
10. obsažnost značkování není příliš důležitá.

Úspěšnost tohoto metajazyka dokazuje také to, že v poslední době o něm vychází mnoho publikací, existují výukové kurzy, jeho podpora je implementována do nejrůznějších programovacích jazyků a v neposlední řadě existuje nepřeberná řada aplikací. Pro příklad jich pár uvedu:

1) Vector Markup Language (VML)

ukládání vektorové grafiky

2) Mathematical Markup Language (MathML)

formátování matematických vzorců a vědeckých výpočtů na webu

3) Geography Markup Language (GML)

ukládání a výměna geografických informací

4) Extensible Hyper Text Markup Language (XHTML)

vytváření webových stránek HTML, které jsou platnými dokumenty XML

5) Scalable Vector Graphics (SVG)

popisuje dvojrozměrnou vektorovou grafiku

6) RSS

čtení novinek na webových stránkách

7) aj.

Předchozí příklady jsou jen nepatrným výčtem z XML aplikací. Rovněž je zajímavé, jak se XML metajazyk rozšířil do nejrůznějších oborů lidské činnosti. Tyto uvedené aplikace jsou nejenom vyvinuté, ale i dále rozšiřované a poměrně i známé lidem, kteří pracují s PC.

Jak je z předchozího textu o XML patrné, tak každý si může vytvořit jakékoliv vlastní schéma pro určitá data. Pro názorný příklad si představme, že máme vytvořit XML pro ukládání dat PSČ obcí České republiky. Nejdříve si musíme udělat rozbor všech dat, která budeme ukládat. V nejjednodušším případě nás bude zajímat název obce a její PSČ. Potom by takové schéma vypadalo asi takto:

Je přirozené, že jiná osoba, jenž by se takovéto schéma pokusila vytvořit, by k zadanému problému přistoupila jinak. Výsledek by potom mohl vypadat zcela odlišně, například takto:

Jedná se o uložení těch samých informací do XML schématu, které je správně strukturované. Problém by nastal v aplikaci, která by byla určena k načítání prvního schématu. V případě pokusu načíst druhé schéma by pak selhala. Proto se u každého XML schéma, jenž má sloužit širší veřejnosti, doporučuje použití jmenného prostoru, který odliší tyto dvě schémata a řekne aplikaci, že nenačítá správné schéma. Tyto dvě definice se mohou lišit v těchto rozdílech:

• použití různého kódování pro uložení dat
• použití různých názvů atributových a tagových značek
• rozdíl ve velikosti písma těchto značek
• rozdílnost jmenných prostorů
• rozdílnost v ukládání dat buď do tagů, atributů nebo kombinací obou způsobů

[Kapitola 2]   [2.2 Přehled využívaných technologií]   [2.2.3 XML (EXtensible Markup Language)]
[Obsah]

2.2.4 DTD (Document Type Definition)

U XML dokumentů existuje rozdíl mezi správně strukturovanými dokumenty a platnými dokumenty XML. Správně strukturované dokumenty musí být validní podle specifikace XML. Platné dokumenty jsou takové, které jsou definovány pomocí Document Type Definition (DTD) [28] , nebo XML schématu (XSD). DTD a XSD můžeme chápat jako omezení metajazyka XML na jeho pouhou aplikaci. Díky tomu se může kdykoliv ověřit platnost XML dokumentu. Dále je tím plně popsána struktura dané aplikace XML.

DTD, neboli definice typu dokumentu, má vlastní syntaktická pravidla, jenž je zapotřebí znát. Výhodou je potom dobrá čitelnost struktury XML. Nevýhodou se pak stávají mnohá omezení, která DTD skrývá. Jedná se například o omezení v definici vlastních datových proměnných.

[Kapitola 2]   [2.2 Přehled využívaných technologií]   [2.2.4 DTD (Document Type Definition)]
[Obsah]

2.2.5 XSD (XML Schema Definition)

Funkce XML schémat (XSD) [15] [28] je stejná jako u jazyka DTD, ale na rozdíl od něj nemá vlastní syntaktická pravidla. XSD využívá metajazyk XML, který oproti DTD rozšiřuje jeho nožnosti. Jak již bylo zmíněno v předešlém bodě, tak příkladem praktické možnosti je definice vlastního datového typu, např. PSČ.

[Kapitola 2]   [2.2 Přehled využívaných technologií]   [2.2.5 XSD (XML Schema Definition)]
[Obsah]

2.3 URL pro GetCapabilities dotaz

Protokol HTTP podporuje dvě metody dotazů GET a POST. Podpora metody GET na straně WMS serveru je povinná. Metoda POST nemusí být daným serverem podporována (je volitelná). Dotaz obsažený v URL (metoda GET HTTP) je velice důležitý pro WMS, protože na jehož základu funguje komunikace mezi serverem (rozumí se jím WMS server) a klientem (rozumí se jím software, jenž komunikuje se serverem).

Server musí umožňovat zpracování těchto dotazů. Většinou se lze na internetu setkat s použitím URL dotazů na dynamické webové stánky (PHP, ASP, aj.).

[Kapitola 2]   [2.3 URL pro GetCapabilities dotaz]
[Obsah]

2.3.1 Omezení URL v aplikaci na WMS

Je v celku pochopitelné, že pro WMS musí existovat určité omezení z hlediska URI, resp. URL. OGC specifikace [51] připouští pouze komunikační protokol HTTP. Vlastní adresa služby musí být validní URL.

http://host[:port]/path?{name[=value]&}

Poznámka:
            [] hodnota v této závorce se může vyskytovat 0 nebo 1 krát
            {} hodnota v této závorce se může vyskytovat 0 nebo N krát

Dotazy na server u všech třech hlavních WMS funkcí probíhají prostřednictvím metody GET protokolu HTTP. Existuje omezení pro používání libovolných znaků, protože některé jsou rezervovány pro speciální účel (viz. tabulka 2.5).

[Kapitola 2]   [2.3 URL pro GetCapabilities dotaz]   [2.3.1 Omezení URL v aplikaci na WMS]
[Obsah]

2.3.2 Tvar URL pro získání XML souboru dotazu GetCapabilities

Pro přístup k určitému WMS serveru je potřeba znát jeho URL, například: http://gis.kr-vysocina.cz/wmsconnector/com.esri.wms.Esrimap. Při znalosti specifikace WMS je možné sestavit kompletní adresu pro dotaz GetCapabilities.

Za tuto adresu je zapotřebí přidat dva povinné parametry, a to REQUEST=GetCapabilities a SERVICE=WMS výsledné URL vypadá poté následovně http://gis.kr-vysocina.cz/wmsconnector/com.esri.wms.Esrimap?SERVICE=WMS&REQUEST=GetCapabilities

V tuto chvíli mohou nastat dvě možnosti. Mapový server klientovi zpřístupní XML soubor nebo k tomu vůbec nedojde. Existuje-li soubor a zároveň bude buď plně validní XML dotazu GetCapabilities (pro libovolnou WMS verzi), jedná se skutečně o URL k WMS serveru. Jedná-li se o XML soubor Exception, nastala chyba v požadavku na server. Server tudíž zpřístupní velice jednoduché XML se zprávou o nastalé chybě.

[Kapitola 2]   [2.3 URL pro GetCapabilities dotaz]   [2.3.2 Tvar URL pro získání XML souboru dotazu GetCapabilities]
[Obsah]

2.3.3 Postup pro získání XML souboru dotazu GetCapabilities

Jak už bylo uvedeno dříve, tak přístup k mapové službě vyžaduje znalost URL mapového serveru. Pokud máme danou adresu, můžeme si ověřit zda je náš předpoklad správný. Z tabulky 2.6 vyplývá, že pro tento dotaz jsou povinné jen dva parametry, a to v celém průběhu vývoje všech verzích kromě jedné výjimky. Jedná se o povinné parametry SERVICE=WMS a REQUEST=GetCapabilities, ale v první veřejně publikované verzi 1.0.0 parametr request vypadal takto REQUEST=Capabilities.

Stanovení specifikace a její aplikace jsou dvě rozdílné věci, což dokazují některé mapové servery, jež vyžadují ještě jeden dle OGC nepovinný parametr. A to VERSION=version.

Iterační postup pro stanovení URL na GetCapabilities dotaz by mohl na následujícím fiktivním příkladu vypadat takto:
http://www.mapyCR.cz/wms/isapi.dll?SERVICE=WMS&SERVICENAME=doprava&REQUEST=GetCapabilities

Vlastní postup:

1) http://www.mapyCR.cz/wms/isapi.dll?SERVICE=WMS&SERVICENAME=doprava&REQUEST=GetCapabilities

kontrola popř. doplnění SERVICE=WMS a REQUEST=GetCapabilities

2) http://www.mapyCR.cz/wms/isapi.dll?SERVICE=WMS&SERVICENAME=doprava&REQUEST=GetCapabilities&VERSION=1.1.1

převzat předchozí případ a doplnit URL o VERSION=1.1.1 tento bod provádět se záměnou hodnoty parametru version (1.1.0, 1.0.7, 1.0.0, 1.3.0)

3) http://www.mapyCR.cz/wms/isapi.dll?SERVICE=WMS&SERVICENAME=doprava&REQUEST=Capabilities

převzít prvotní URL a zkontrolovat, popř. doplnit SERVICE=WMS, zkontrolovat a pokud se vyskytuje, umazat parametr REQUEST=GetCapabilities, přidat REQUEST=Capabilities

4) http://www.mapyCR.cz/wms/isapi.dll?SERVICE=WMS&SERVICENAME=doprava&REQUEST=Capabilities&VERSION=1.0.0

převzat předchozí případ a doplnit URL o VERSION=1.0.0, tento bod provádět se záměnou hodnoty parametru version (1.0.7, 1.1.0, 1.1.1, 1.3.0)

5) http://www.mapyCR.cz/wms/isapi.dll?SERVICE=WMS&SERVICENAME=doprava&REQUEST=Capabilities&VERSION=1.3.0

poslední možný pokus o sestavení URL dotazu GetCapabilities

Předpokladem tohoto postupu je to, že pokud je předáno URL s query parametry, tak se tyto parametry považují prvotně za správné, teprve až v dalším postupu se začínají považovat za špatné. Pokud by dotaz obsažený v query neexistoval, tak by byl sestavován stejným postupem.

Správné URL by bylo to, které v průběhu předchozího postupu získalo přístup k XML souboru dotazu GetCapabilities (viz. tabulka 1.8).

[Kapitola 2]   [2.3 URL pro GetCapabilities dotaz]   [2.3.3 Postup pro získání XML souboru dotazu GetCapabilities]
[Obsah]

2.4 Rozbor XML souboru dotazu GetCapabilities

Struktura tohoto XML souboru má určitá pravidla, jimiž se musí mapový server řídit. Popis struktury XML souboru metadat je uveden ve formátech Definice typu dokumentu (DTD) a XML schéma (XSD) na webové stránce [12]
http://schemas.opengeospatial.net/wms/

Poznámka: 1) daná verze má více souborů viz. tabulka 2.8

Rozdíl mezi těmito soubory (především DTD) je v tom, že se měnily tyto hodnoty:

• název úvodního tagu (viz. tabulka 2.9)
• vznikaly (zanikaly) nové tagy, jež se staly nositeli nových informací
• měnily se názvy tagu
• měnilo se uložení dat v atributech nebo v tagu

[Kapitola 2]   [2.4 Rozbor XML souboru dotazu GetCapabilities]
[Obsah]

2.4.1 Obsah XML souboru dotazu GetCapabilities

Tento metadatový soubor obsahuje překvapivě hodně informací, ke kterým běžný uživatel nemá přístup.

A) údaje o serveru:

Jedná se o informace, jež podrobně charakterizují celý mapový server. Data jsou vnořena do těchto tagu <WMT_MS_Capabilities>, <Service>.

- základní informace:

název, nadpis, abstrakt, klíčová slova charakterizující server, URL serveru

- kontaktní informace:

odpovědná organizace, osoba a její pozice

- adresa správce:

typ adresy, adresa, město, stát, provincie nebo část státu, PSČ, telefon, email

- ostatní informace:

omezení přístupu, zpoplatnění, omezení počtu vrstev, maximální rozměr výstupu obrazových dat (v pixelech)

B) údaje o dotazech na server:

Zde jsou vyjmenovány veškeré typy dotazů, jež je možno provádět na daný server. U těchto typů jsou dále určeny metody HTTP dotazů (GET, POST) a formáty datových výsledků, které server vrátí po příslušném dotazu. Data jsou vnořena do těchto tagu <WMT_MS_Capabilities>, < Capability>, < Request>.

- dle OGC:

GetMap, GetCapabilities, GetFeatureInfo

- ostatní:

DescribeLayer, aj.

C) formát zprávy o výjimce:

V určitých případech může nastat případ, kdy server nepochopí daný dotaz nebo nastane jiná interní chyba. Zprávu o této chybě poskytuje klientovi ve formátu, jenž je zde jmenován. Data jsou vnořena do těchto tagu < WMT_MS_Capabilities>, <Exception>.

XML soubor, obrazová prezentace, popř. jiné formáty.

D) údaje o dostupných vrstvách:

Tato část souboru metadat serveru je pro uživatele asi nejzajímavější. Obsahuje seznam všech poskytovaných vrstev a jejich stylů. Vrstvu ve WMS si lze představit jako tematickou mapu. Příkladem může být vrstva ortofotomapy. Data jsou vnořena do těchto tagu <WMT_MS_Capabilities>, <Layer>.

<Layer>:

Úvodní tag layer je jen jeden. Následují informace, jež jsou společné pro všechny vrstvy. Ostatní vrstvy jsou vnořovány do úvodního tagu layer a do jiných už vnořených tagu layer. Některé atributy těchto vnořených vrstev dědí informace, jež jsou uvedeny v nadřazené vrstvě, pokud tato informace není přepsána (tabulka 2.11).

<Name>:

Jméno vrstvy (souvislý řetězec) se používá jako součást dotazu GetMap.

<Title>:

Titulek vrstvy je popis vrstvy (pro člověka čitelný).

<Abstract>:

Jedná se o popis vlastností vrstvy (mapy).

<KeywordList>:

Obsahuje klíčová slova popisující danou vrstvu. Má především význam pro vyhledávání.

<Style>:

Zde se nachází popis stylů vrstvy. (více popsáno v bodě E)

<SRS>:

Spatial Reference System (SRS) nově označován jako Coordinate Reference System (CRS) slouží pro výčet souřadnicových systemů, která daná vrstva podporuje. Uvádí se ve formátu Namespace:ID. Nejčastěji se využívá dataset EPSG organizace The International Association of Oil & Gas producers (OGP). Podrobněji je EPSG popsáno v příloze E).

<LatLonBoundingBox>:

Území, které zobrazuje určitá vrstva, je vymezeno (omezeno) ohraničujícím obdélníkem (boxem) v souřadnicovém v systému WGS1984 lat/lon dané kódem EPSG:4326. Tento obdélník je jednoznačně určen parametry minx, maxx v souřadnicích zeměpisné délky (longitude) a miny, maxy v souřadnicích zeměpisné šířky (latitude) v uvedených desetinných stupních.

<BoundingBox>:

Tento tag je analogií k <LatLonBoundingBox>. Je zde stejným způsobem vymezeno území zobrazené danou vrstvou, ale pro libovolný souřadnicový system (CRS), který je uveden v <SRS>.

<Dimension>:

Jedná se o definici dimenze a její jednotek, např. dimenze time a jednotka ISO8601.

<Extent>:

Využívá definované dimenze vrstvy <Dimension> a vymezuje tuto dimenzi na jeden nebo více domén např. dimenze time a doména 2000-08-22.

<Attribution>:

Odasahuje popis atributů a jejich URL odkaz.

<AuthorityURL>:

Odkazuje na URL správce (vlastníka) dat dané vrstvy a vymezuje jejich formát. Protože vlastníků může být více, využívá tag <Identifier> pro vazbu mezi tímto tagem.

<Identifier>:

Jedná se o štítek pro pro definování jména (name) využívané potom v <AuthorityURL>.

<MetadataURL>:

Odkazuje na URL obsahující metadata dané vrstvy a vymezuje jejich formát.

<DataURL>:

Odkazuje na URL obsahující data dané vrstvy a vymezuje jejich formát. Metadata těchto dat popisuje tag <MetadataURL>.

<FeatureListURL>:

Odkazuje na URL obsahující vlastnosti dané vrstvy a vymezuje jejich formát.

<ScaleHint>:

Protože vrstvu lze chápat jako mapu zobrazující dané území s určitou podrobností (stupněm generalizace), tak je vcelku pochopitelné, že pro vrstvu např. silniční mapy bude existovat měřítková mez pro její zobrazení. V malém měřítku by tato mapa byla nečitelná. Tomu se lze vyhnout poskytnutím této mapy s různými stupni generalizace s vymezením měřítkové meze pro zobrazení.

E) údaje o dostupných stylech vrstvy:

Styl je poté jakási drobná změna v tematické vrstvě. Může jít například o změnu barvy elementů, u dat získaných pomocí DPZ může jít o zobrazování různých části barevného spektra (panchromatické barvy). Data jsou vnořena do těchto tagu <WMT_MS_Capabilities>, < Layer>.

<Name>:

Jméno vrstvy (souvislý řetězec) používá se jako součást dotazu GetMap.

<Title>:

Titulek vrstvy je popis vrstvy (pro člověka čitelný).

<Abstract>:

Jedná se o popis vlastností stylu vrstvy (mapy).

<LegendURL>:

Odkazuje na URL obsahující legendu daného stylu vrstvy a vymezuje formát této legendy.

<StyleSheetURL>:

Odkazuje na URL popisující symboliku informací stylu vrstvy a formát tohoto popisu.

<StyleURL>:

Odkazuje na URL obsahující podrobnější informace popisující styl vrstvy a formát tohoto popisu.

[Kapitola 2]   [2.4 Rozbor XML souboru dotazu GetCapabilities]   [2.4.1 Obsah XML souboru dotazu GetCapabilities]
[Obsah]

Kapitola 3

Vyhledávání WMS serverů

Protože je tento prostředek pro šíření mapových produktů poměrně mladý, tak teprve až v posledních dvou letech se začínají ve větší míře vyskytovat stránky, které informují o této službě. Na některých existuje i možnost vyhledávání WMS serverů spolu s jejich vrstvami a styly.

[Kapitola 3]
[Obsah]

3.1 Současné možnosti vyhledávání

3.1.1 Stávající situace seznamů WMS serverů na internetu

1) http://www.ogc-services.net/ [41]

Tato stránka spravuje seznam WMS serverů z celého světa. Je zde uveden název serveru, počet dostupných vrstev, datum přidání, URL GetCapabilities dotazu a abstrakt. Dále tu existuje formulář na přidání další služby. Možnost vyhledávání je zde řešena pomocí google vyhledávacího pole.

2) http://exploreourpla.net/gis/maps/ [42]

Tato stránka spravuje seznam WMS serverů z celého světa. U daného WMS je uveden název serveru, jsou vyjmenované dostupné vrstvy s geografickým omezením. Možnost vyhledávání je zde řešena pomocí interního vyhledávacího pole.

3) http://www.skylab-mobilesystems.com/en/wms_serverlist.html [43]

Jedná se o verzi WMS seznamu, od které bylo upuštěno. Novou možností je http://www.ogc-services.net/ (popsáno v 1. bodě). Obsahuje seznam serverů s počtem vrstev. Po kliknutí na odkaz serveru je možno získat XML dotazu GetCapabilities.

4) http://wms-sites.com/ [44]

Tento portál je zatím doposud asi jeden z nejlepších pro správu informací o WMS serverech. U WMS serveru jsou evidovány tyto informace: název, počet vrstev, URL GetCapabilities dotazu a čas změny. Po kliknutí na odkaz serveru se zobrazí dostupné informace o dostupných vrstvách serveru: název, jméno a podporované souřadnicové systémy. Dále se zde nachází formulář na přidání další služby. Portál poskytuje poměrně podrobné vyhledávání dle klíčových slov.

5) http://columbo.nrlssc.navy.mil/ogcwms/servlet/WMSServlet/ [62]

Tato stránka obsahuje poměrně velké množství (ke dni 29. 5. 2007 1371 URL) WMS serverů. Jsou zde řazeny dle názvu serverů. Dále je uvedeno URL WMS serveru a odkaz na XML dotazu GetCapabilities.

[Kapitola 3]   [3.1 Současné možnosti vyhledávání]   [3.1.1 Stávající situace seznamů WMS serverů na internetu]
[Obsah]

3.1.2 Další možnosti vyhledávání WMS serverů

1) využití možností internetových vyhledávačů

Jedná se o použití internetových vyhledávacích portálů, jakými jsou například: www.google.com, http://www.yahoo.com/, http://www.altavista.com/, http://www.seznam.cz/, atd. U takovýchto vyhledávacích portálů lze použít jak základní, tak i pokročilé vyhledávání údajů. Hledání může probíhat za použití nejrůznějších kombinací klíčových slov, jimiž jsou např: "wms", "map", "web map server", "ogc", "service", "server", atd.

2) využití metainformačních systémů

Jde o informační systém (tenký, tlustý popř. kombinace obou), který se specializuje na hledání údajů v metadatech. Dokáže pak na něj klást nejrůznější požadavky. Takovým produktem je např. MIcKA [45] (Metainformační katalog) firmy HELP SERVICE - REMOTE SENSING s.r.o. sídlící v Benešově.

[Kapitola 3]   [3.1 Současné možnosti vyhledávání]   [3.1.2 Další možnosti vyhledávání WMS serverů]
[Obsah]

3.2 Návrh nových způsobů vyhledávání dat spravovanými WMS servery

Jedná se o úvahy, jaké formy hledání mezi těmito daty by mohly být aplikovány na vytvářený portál o webových mapových službách. Některé z těchto zjištěných byly následně aplikovány do vyhledávací sekce portálu.

Předpokladem je, že máme jakýmsi způsobem centralizována metadata (XML soubory dotazu GetCapabilities).

Jednou variantou by bylo mít data umístěna ve složce a portál by poté prohledával jednotlivé soubory a hledal server, vrstvu nebo styl vrstvy, který by vyhovoval hledané informaci. Tento způsob postupu by byl velice zdlouhavý a nepraktický. Často by potom mohlo dojít k situaci, kdy se PHP skript obsluhující toho hledání přeruší vlivem proměnné omezující max. dobu provádění skriptu.

Daleko výhodnější variantou by bylo načtení tohoto souboru do databáze např. MySQL. Předpokladem je vytvoření kvalitní struktury databáze, aby dokázala pojmout informace uložené v XML souboru. Tato databáze by měla potom mít logicky vytvořené tabulky. Sloupce tabulek by měly být omezeny použitím správných datových typů, volbou jejich výchozích hodnot, délkou datového typu, a volbou, zda jsou povinné či ne pro zápis (stanovením domén).

[Kapitola 3]   [3.2 Návrh nových způsobů vyhledávání dat spravovanými WMS servery]
[Obsah]

3.2.1 Způsoby hledání mezi WMS servery

1. fulltextové hledání:

   Jde o způsob hledání dat pomocí zadaného (hledaného) slova v určitých údajích metadat. Značky (tagy) ve kterých má smysl hledat:

   - server:

   <Version>, <Name>, <Title>, <Abstract>, <Keyword>, <ContactPosition>, <Address>, <City>, <StateOrProvince>, <Country>, <ContactPerson>, <ContactOrganization>

   - layer:

   <Name>, <Title>, <Abstract>, <Keyworld>, <CRS>, <Attribution> - <Title>

   - style:

   <Name>, <Title>, <Abstract>

   Výsledkem hledání např. slova "voda" by poté měl být seznam pozitivních výsledků se zobrazením potřebných dat:

   server: URL serveru, název serveru

   vrstva: URL serveru, název serveru, název vrstvy

   styl vrstvy: URL serveru, název serveru, název vrstvy, název stylu vrstvy

2. fulltextové hledání specializované:

   Jde o ten samý princip hledání, jak je uveden v bodě 1), ale na rozdíl od něj se zobrazí pouze pozitivní výsledky v kategorii server, vrstva nebo styl vrstvy.

3. geografické hledání dle bodu v souřadnicích WGS84:

   Z informací o rozboru metadat WMS serveru vyplývá, že území které je zobrazované pomocí vrstev jedním WMS serverem, je ohraničeno geografickým boxem. Tento box je dán zeměpisnou délkou (longitude) a šířkou (latitude) v desetinných stupních. Jedná se o souřadnice v systému WGS1984 lat/lon dané kódem EPSG:4326.

   Je-li potom dán bod (zeměpisná délka a šířka), tak podle něj chceme najít všechny dotčené WMS servery. Postup hledání názorně ilustruje obrázek 2.

   

   Obrázek 8 - Ukázka geografického hledání dle bodu

4. geografické hledání dle boxu v souřadnicích WGS84:

   Pokud bychom chtěli dle 3) najít WMS servery zobrazující například území města, tak bychom skoro určitě neuspěli. Město svou nepatrnou rozlohou deformuje ohraničující geografický box do bodu. Postup pro hledání takového mapového serveru by mohl být následovný. Vytvořil by se hledací box, jenž by obsáhl souřadnice bodu města. U takovéhoto boxu by v obecném případě z hlediska geografické rozlohy území mohly nastat tyto případy:

   - hledaný box by svou rozlohou ležel uvnitř boxu WMS serveru (100% překryt)

   - hledaný box by svou rozlohou ležel částí na boxu WMS serveru (0% < x < 100% překryt)

   - hledaný box by svou rozlohou nezasáhl do boxu WMS serveru (0% překryt)

   

   Obrázek 9 - Ukázka geografického hledání dle boxu

   Abychom nemuseli řešit polohu boxů z hlediska zemských kvadrantů pro výpočet plochy, posuneme počátek soustavy tak, aby celá Země měla kladné zeměpisné souřadnice.

   lon_II=lon_I+180°

   lat_II=lat_I+90°

   Tento posun se musí provést se souřadnicemi hledaného bodu (obr. 5).

   

   Obrázek 10 - Posun počátku zeměpisného souřadnicového systému

5. geografické hledání dle bodu v souřadnicích obecného souřadnicového systému:

   U každé vrstvy jsou vyjmenovány podporované souřadnicové systémy (CRS). Každý tento systém může mít prostorové omezení (box). Je to obdobný princip jako u geografického zeměpisného boxu. Potom při volbě CRS například EPSG:2065 (S-JTSK) lze obdobně postupovat jako při geografickém hledání dle bodu 3).

6. geografické hledání dle boxu v souřadnicích obecného souřadnicového systému:

   Tak jak je uvedeno v geografické hledání dle boxu v souřadnicích WGS84, tak by se dalo postupovat při hledání s volbou CRS, například EPSG:2065 (S-JTSK).

[Kapitola 3]   [3.2 Návrh nových způsobů vyhledávání dat spravovanými WMS servery]   [3.2.1 Způsoby hledání mezi WMS servery]
[Obsah]

Kapitola 4

Webový portál o WMS

Zcela jistě můžu tvrdit, že kterýkoliv běžný uživatel internetu nemá potuchy o možnosti prohlížet si mapová data území celého světa a dokonce i jiných planet. Přitom existuje celá řada prostředků, jenž mu webové mapové služby resp. jejich servery dokáží zpřístupnit, a to jak prostřednictvým webových aplikací (tenký klient) nebo softwarových produktů (tlustý klient). Cílem této bakalářské práce je snaha zasvětit případného návštěvníka těchto stránek do webové mapové služby a umožnit mu vyhledat jakýkoli WMS server nacházející se v databázi.

Pro koho jsou tedy tyto stránky určeny? Pro kohokoliv, koho zajímají mapové produkty a informační technologie. Portál mohou využívat školy jako prostředek podpory výuky např. v předmětu kartografie, soukromé subjekty, jenž mají zájem o využití WMS, státní správa, resp. magistráty, aj. úřady.

Stránky jsou vytvořeny v poměrně novém značkovacím jazyku pro tvorbu XHTML ve verzi 1.1. Nelze je však chápat jako statický web, protože jsou vytvořeny ve skriptovacím jazyku PHP, který má zajistit snazší obsluhu a údržbu portálu. Jejich vzhled je ovlivněn souborem kaskádových stylů vytvořených pro obrazovku monitoru.

Stránky byly optimalizovány pro rozlišení 1024x768px. Uživateli s větším rozlišením se zobrazí informace v šířce 768px zarovnané vlevo k obrazovce. V opačném případě nebude vidět kompletně stránka, ale bude k ní přístup pomocí posuvných lišt. Vzhled a správné zobrazování byly zkontrolovány v prohlížečích Firefox 1.5.0, Internet Expolorer 6 a Opera 8.

[Kapitola 4]
[Obsah]

4.1 Informační sekce webového portálu

Prvotní snahou je návštěvníka informovat o webových mapových službách (WMS) a možnostech jejich využití, s uvedením praktických příkladů. Uživatel by se hned v úvodu měl dozvědět k čemu WMS je a pro koho je určeno. Dále zjistí informace o historickém vývoji této služby a popřípadně o budoucnosti vývoje. Poté by měl vidět praktické ukázky toho, co WMS dovede. Důležitou informací by mělo být pro něj i seznam produktů (tenké a tlusté klienty) podporující připojení WMS, popřípadně návod na jejich používání.

Úvodní strana se skládá ze čtyř logických částí, jenž jsou obvyklé na mnoha jiných portálech. Jedná se o záhlaví, postranní lištu, vlastní obsah a zápatí.

Tato struktura obsahu byla vytvořena pomocí kaskádových stylů.

V záhlaví se nacházejí dva obrázky, které odkazují zpět na úvodní stranu. První z nich je logo stránek a druhé je obrázek s mapovými produkty šířenými pomocí WMS.

V postranní liště se nachází jako první rozevíratelné nabídkové menu, odkazující na základní informace o WMS. Prvek "novinky" odkazuje na seznam uložených článků, které sice souvisí s mapovými službami, ale obsahují informace, jenž se nedají zařadit k základním informacím. Dalším boxem odkazů je omezení článků dle jejich kategorií. Příkladem je odkaz na omezení "tenký-klient". Pro možnost vyhledávání na těchto stránkách je zde přidáno pole pro vyhledávání pomocí vyhledávače www.google.com. Předposlední informací v postranní liště jsou statistiky portálu (návštěvnost a dostupnost portálu). Jako poslední jsou uvedeny odkazy, jenž souvisí s obsahem portálu.

V boxu "vlastní obsah" se nacházejí vlastní informace získané pomocí kliknutím na odkazy z postranní lišty.

Součástí zápatí jsou odkazy na kontrolu platnosti (validity) formátů XHTML 1.1 a CSS2.

Obrázek 11 - Vzhled informační sekce portálu

[Kapitola 4]   [4.1 Informační sekce webového portálu]
[Obsah]

4.2 Vyhledávací sekce webového portálu

Problém pro běžného uživatele by nastal hned na začátku, a to v neznalosti URL mapového serveru WMS. Bez znalosti této adresy není možno žádnou vrstvu připojit. Na internetu pomocí vyhledávačů, jimiž jsou např. www.google.com, www.seznam.cz, je možno si potřebné URL vyhledat. Problém nastává, pokud hledáme specifická mapová data. A to je dalším cílem této práce vytvořit jakýsi seznam WMS serverů zasahující naše území. Výhodou tohoto seznamu, jenž zpracuje metadata o WMS serveru, je centralizování všech metadat do interní databáze.

Na takovouto naplněnou databázi je potom snadné klást nejrůznější dotazy. Například:

• jaké procento WMS služeb pracuje ve verzi 1.1.1?,
• jaký je počet vrstev u určitého serveru,
• dle zeměpisných souřadnic nalézt všechny vrstvy, které dané území zobrazují,
• vyhledat všechny vrstvy, servery popř. styly vrstev, jenž mají něco společného s daty spravovanými ČUZK,
• vyhledat dle souřadnice bodu v S-JTSK všechny zasahující vrstvy,
• vyhledat všechny vrstvy dle klíčového slova např. "voda",
• exportovat URL všech mapových serverů např. do formátu XML,
• aj.

Obrázek 12 - Prohlížení seznamu WMS serverů (databázová sekce)

Obrázek 13 - Prohlížení jednoho WMS serveru (databázová sekce)

Obrázek 14 - Prohlížení vrstvy WMS serveru (databázová sekce)

[Kapitola 4]   [4.2 Vyhledávací sekce webového portálu]
[Obsah]

4.2.1 Přehled vytvořených PHP tříd

Kdyby se měla vyhledávací část portálu vytvořit pomocí klasického procedurálního programování, které využívá pro vykonání úloh proměnné a funkce, tak by brzo nastal zmatek v tom, co každá funkce obsluhuje. Výhodnější z hlediska objektově orientovaného programování (OOP) je práce s třídami.

Objekt (třída) obsahuje jak data (například proměnné), tak popis a způsob, jak s nimi manipulovat (členské metody). Díky tomu může zjednodušeně řečeno objektové programování řešit některé věci pružněji než procedurální. Hlavní výhodou objektu je fakt, že umožňuje popisovat věci tak, jak fungují v běžném životě. Například automobil má určité vlastnosti (barvu, typ, spotřebu apod.), ale rovněž určité věci umí (mohli bychom popsat metodami JedDoMista, Natankuj, Stuj a podobně). V objektově orientovaných jazycích hovoříme o tom, že objekty mají stav ("co to je") a chování ("co to umí").

Objekty se v OOP musejí nejprve nadefinovat. K definici objektu slouží takzvané třídy. Třída je něco jako šablona nebo prototyp, na jehož základě se budou objekty tvořit. V PHP se třída definuje pomocí klíčového slova class.

Seznam vytvořených tříd:

1) c_GC_100.php, c_GC_107.php, c_GC_110.php, c_GC_111.php, c_GC_130.php

Třídy, které obsluhují zpracování obsahu XML souboru dotazu GetCapabilities do proměnné typu pole. Je jich celkem pět, a to z důvodu stejného počtu verzí XML souboru získaného tímto dotazem. Každý z těchto souborů je rozdílný z hlediska použitých názvů tagu, jejich obsahu, apod.

2) c_GC2db.php

Třída pro načtení pole s XML souborem do databáze MySQL.

3) c_db2tab.php

Třída pro zobrazení záznamů z databáze do tabulek ve formátu XHTML.

4) c_searchWMS.php

Třída pro hledání v databázi dle nejrůznějších parametrů. Vrací indexy pozitivních výsledků.

5) c_dbsearch2tab.php

Třída pro zobrazení pozitivních výsledků z databáze do tabulek ve validním formátu XHTML.

6) c_export2xml.php

Třída pro export WMS serverů a jejich základních parametrů do XML formátu.

7) c_updateDB.php

Třída pro zajištění opětovné aktualizace databáze a kontroly obsahu databáze.

8) c_URL_wms.php

Třída, která obsahuje spoustu členských funkcí pro testy na GetCapabilities dotaz.

[Kapitola 4]   [4.2 Vyhledávací sekce webového portálu]   [4.2.1 Přehled vytvořených PHP tříd]
[Obsah]

4.3 Použité jazyky pro vytvoření portálu

4.3.1 PHP (PHP Hypertext preprocessor)

PHP je skriptovací jazyk pro tvorbu dynamických internetových stránek. Vznikl kolem roku 1994. Tehdy se pan Rasmus Lerdorf rozhodl vytvořit jednoduchý systém pro počítání přístupu ke svým stránkám. Původně byl tento kód napsán v PERLu. Později, z důvodu zátěžování kódu serveru byl systém přepsán do jazyka C. Sada těchto skriptů byla ještě později téhož roku vydána pod názvem "Personal Home Page Tools, zkrácene PHP (pozdější název "Personal Home Page Construction Kit").

U toho však nezůstalo. V polovině roku 1995 se systém PHP spojil s jiným programem stejného autora, a to s nástrojem "Form Interpreter" neboli zkrácene FI. Tak vznikl PHP/FI 2.0, systém, který si získal celosvětovou proslulost a byl velmi rozšířen. Od poloviny roku 1998 byla k dispozici verze 3.0, která byla mnohem rychlejší, a vybavenější než verze 2.0, která byla k dispozici rovněž pod Windows. Počet webu, které používaly PHP se zvyšoval, až dosáhl cca 150 000. Do rodiny verzí 5 bylo přidáno mnoho nových funkcí a rovněž bylo přepracované jádro Zend.

Podle údajů z dubna 2004 pracuje s PHP přes 15 000 000 domén, a to je bezkonkurenčně nejčastěji používaný modul Apache serveru. Zkratka PHP by se měla dle moderního pojetí překládat jako "PHP: Hypertext preprocessor", česky bychom nazvali "předzpracovávač hypertextu".

V současné době je již k dispozici verze PHP 5. Je obohacena o jádro Zend II, kompletně přepsaná podpora XML, nové objektové rozhraní pro práci s databází MySQL a mnoho dalšího. Z toho vyplývá, že systém je stále vybavován novými technologiemi a je aktivně vyvíjen.

[Kapitola 4]   [4.3 Použité jazyky pro vytvoření portálu]   [4.3.1 PHP (PHP Hypertext preprocessor)]
[Obsah]

4.3.2 XHTML (eXtensible Hypertext Markup Language)

XHTML je zkratkou anglického názvu eXtensible Hypertext Markup Language a v překladu znamená "rozšiřitelný značkovací jazyk pro hypertext". Narozdíl od svého předchůdce HTML a jeho vývojových verzí, se hlavním principem nového formátu webových stránek stalo striktní dodržení syntaktických pravidel XML. Jedná se tedy o obdobný jazyk jako HTML sloužící pro tvorbu hypertextových dokumentů v prostředí internetu. Tuto aplikaci XML vyvinulo konsorcium W3C. Narozdíl od svého předchůdce HTML jehož vývoj se zastavil, je XHTML poměrně mladý a rozvíjející se jazyk.

Postup vývoje XHTML začal verzí XHTML 1.0, jejímž hlavním cílem bylo splnit podmínky XML dokumentů se zachováním zpětné kompatibility. Tento vývojový stupeň umožňoval zápis struktury ve třech různých modifikacích Strict, Transitional a Frameset.

Verze XHTML 1.1 již vynechává prakticky všechny prezentační vlastnosti a je hodně podobná verzi Strict. V současné době pracuje pracovní skupina XHTML W3C konsorcia na vývoji verze XHTML 2.0.

[Kapitola 4]   [4.3 Použité jazyky pro vytvoření portálu]   [4.3.2 XHTML (eXtensible Hypertext Markup Language)]
[Obsah]

4.3.3 CSS (Cascading Style Sheets)

S rozvojem popularity webu stoupaly nároky autorů www stránek na ovlivňování vzhledu svých HTML dokumentů. Jako jeden z prvních přišel prohlížeč Netscape s implementací formátovacích nástrojů do samotného HTML kód. Tato situace se s postupem času ukázala jako chybná, protože došlo ke sloučení dvou principů, struktury a vzhledu dokumentu v jeden formát. Dodnes ještě neseme negativní důsledky tohoto počinu. Snahu tuto nepříjemnou situaci vyřešit projevilo W3C konsorcium, a to prostřednictvím Cascading Style Sheets (CSS), což v překladu znamená kaskádové styly. Jedná se o nově vytvořený jazyk pro popis způsobu zobrazení dokumentů napsaných v nejrůznějších jazycích HTML, XHTML nebo XML.

Hlavním cílem byla snaha oddělit strukturu a obsah dokumentu od jeho vzhledu. Strukturou a obsahem jsou řetezce, které jsou umístěny do příslušných tagů dle svého významu. Jedná se například o nadpis, odstavec, internetový odkaz, obrázek, atd. Vzhled příslušného dokumentu lze chápat nejjednodušeji v různých barvách písmen, orámování elementů, pozicování na stránce, a spoustě dalších příkladů.

První verze specifikace CSS1 spatřila světlo světa už v roce 1996. V roce 1998 následovalo vydání doporučení specifikace CSS2. A jako důkaz, že kaskádové styly jsou živým formátovacím jazykem pro nejrůznější dokumenty je to, že v současné době se pracuje na verzi CSS3.

Kaskádové styly umožňují připojení CSS k danému dokumentu čtyřmi základními možnostmi.

• prvek <link> (externí soubor)
• prvek <style> (zápis do interního souboru)
• atributy style různých (X)HTML tagů (zápis do interního souboru)
• klientské skriptování a DOM (Document Object Model)

Nejdůležitější význam a umožňění nejširšího využití možností CSS, je zápis do externího souboru, který je připojen k (X)HTML pomocí tagu <link> ležícího uvnitř tagu <meta>. Tento způsob dovoluje definovat zobrazení dokumentů pro nejrůznější druhy médií, např. obrazovka, papír(tisk), kapesní počítač, hlasový syntetizér, apod.

Příklad formátování všech tagů <p> (odstavců), pokud vlivem kaskádování nedojde ke změně těchto hodnot:

[Kapitola 4]   [4.3 Použité jazyky pro vytvoření portálu]   [4.3.3 CSS (Cascading Style Sheets)]
[Obsah]

4.3.4 SQL (Structured Query Language)

Structured Query Language (strukturovaný dotazovací jazyk) SQL je standardizovaný dotazovací jazyk používaný v relačních databázích, který umožňuje klientovi nebo uživateli komunikovat s databázovým serverem a klást na něj nejrůznější dotazy dle možností daného serveru.

Kořeny původu má SQL už v 70. letech 20. století, kdy probíhal ve firmě IBM výzkum relačních databází, což bylo nutné pro ovládání těchto databází. Vznikla vytvořená sada příkazů pro ovládání databáze. Jazyk se jmenoval SEQUEL (Structured English Query Language). Snahou bylo vytvořit jazyk, ve kterém by se příkazy tvořily syntakticky co nejblíže přirozenému jazyku (angličtině).

K vývoji jazyka se postupně připojily další firmy. V r. 1979 uvedla na trh firma Relational Software, Inc. (dnes Oracle Corporation) svůj relační databázový systém Oracle. Poté následovaly další typy databází různých firem. Jazyk SEQUEL se v té době přejmenoval na SQL.

S rostoucím významem relačních databází bylo nutné jejich dotazovací jazyk standardizovat. Americký institut ANSI založil nový standard na SQL, který bývá označován jako SQL-86.

V dalších letech se ukázalo, že SQL-86 obsahuje některé nedostatky a naopak v něm nejsou obsaženy některé důležité prvky týkající se hlavně integrity databáze. V roce 1992 byl proto přijat nový standard SQL-92 (někdy se uvádí jen SQL2). Zatím nejnovějším standardem je SQL3 (SQL-99), který reaguje na potřeby nejmodernějších databází s objektovými prvky.

Standardy podporuje prakticky každá relační databáze, ale obvykle nejsou implementovány vždy všechny požadavky normy. A naopak, každá z nich obsahuje prvky a konstrukce, které nejsou ve standardech obsaženy. Přenositelnost SQL dotazů mezi jednotlivými databázemi je proto omezená.

[Kapitola 4]   [4.3 Použité jazyky pro vytvoření portálu]   [4.3.4 SQL (Structured Query Language)]
[Obsah]

Závěr

Webový portál Web Map Service (WMS), jenž se stal cílem této bakalářské práce, znamenal nejprve pochopit princip WMS normy, a poté následně WMS serveru. Po porozumění těmto principům se mou snahou stalo pochopit obsah a způsob získání XML souboru metadat WMS. Tento soubor obsahuje vysoce hodnotné informace popisující WMS server z mnoha hledisek.

Následně jsem vytvořil webový portál složený ze dvou sekcí. Informační a vyhledávací části.

Informační sekce je naplněna základními informacemi o Web Map Service. Postupně tuto sekci ještě doplním o další informace a dále o výsledky bakalářské práce Jana Říhy na téma Webové mapové služby - datové zdroje. Zajímovou možností této sekce je kromě standardního popisu WMS, možnost aktualizace obsahu pomocí článků rozřazených do několika kategorií. V těchto článcích je pak možno popsat například způsob připojení WMS serveru do nejrůznějších klientů nebo popsat možnosti určitých mapových serverů (WMS serverů).

Vyhledávací sekce je programovou částí portálu vytvořenou pomocí objektově orientovaného programování v jazyce PHP. V této sekci si lze prohlížet možnosti (metadata) WMS serverů uložených v interní databázi. Do této databáze lze přidat další servery, popř. aktualizovat stávající. Aby byla databáze i prakticky využitelná, přidal jsem pět možností vyhledávání. Jsou jimi fulltextové hledání, fulltextové hledání specializované, geografické hledání dle bodu (boxu) v souřadnicích WGS84, geografické hledání dle bodu v souřadnicích obecného souřadnicového systému (podrobněji v odstavci 3.2.1). Informace popisující stav databáze lze najít v části statistiky (počet WMS serverů, podíl jednotlivých verzí, aj.). Zároveň bylo mým záměrem i to, aby tento seznam bylo možno exportovat a využít v nejrůznějších institucích, projektech, apod. Formát tohoto exportu jsem definoval pomocí již dříve zmíněné definice typu dokumentu (DTD).

Tento portál je umístěn na serveru GEO2, katedry Mapování a kartografie, Fakulty stavební, ČVUT

http://geo2.fsv.cvut.cz/wms

Doufám, že tyto stránky budou využívány jak školami (například ČVUT, Fsv, obor Geodézie a kartografie ve výuce předmětů, jenž se soustředují na GIS), tak i institucemi jako je státní správa (např. ČUZK), samospráva (např. krajské úřady) a soukromý sektor.

Přílohy této práce (Webový portál o mapových službách) tvoří výpisy souborů DTD popisující XML dotazu GetCapabilities a popis vyjímky Exception pro nejrozšířenější WMS verzi 1.1.1 včetně příkladu XML dotazu GetCapabilities. Zároveň se zde nalézá výpis struktury MySQL databáze wms_list (Dump) pro ukládání metadat WMS serverů. Dalšími součástmi přílohy jsou také dva články informační sekce portálu a to EPSG (European Petroleum Survey Group) a Podpora Web Map Service (WMS) v GIS krajů ČR. Pro lepší názornost možností WMS jsou zde mapové kompozice náměstí Republiky v Plzni z několika WMS serverů. Poslední přílohu tvoří přiložený kompaktní disk (CD), což je nedílná součást práce.

[Závěr]
[Obsah]

Seznam obrázků

[Seznam obrázků]
[Obsah]

Literatura

[Literatura]
[Obsah]

Příloha A

Capabilities_1_1_1.dtd je soubor popisující (omezující) XML dotazu GetCapabilities. Je zde uvedena jen verze pro WMS 1.1.1, protože v době psaní této práce byla nejrozšířenější. Zdrojem je webový odkaz [12].

Výpis souboru capabilities_1_1_1.dtd

[Přílohy]   [Výpis souboru capabilities_1_1_1.dtd]
[Obsah]

Příloha B

Exception_1_1_1.dtd je soubor popisující (omezující) XML chybného dotazu WMS serveru. Je zde uvedena jen verze pro WMS 1.1.1, protože v době psaní této práce byla nejrozšířenější. Zdrojem je webový odkaz [12].

Výpis souboru exception_1_1_1.dtd

[Přílohy]   [Výpis souboru exception_1_1_1.dtd]
[Obsah]

Příloha C

Capabilities_1_1_1.xml je soubor příkladu XML dotazu GetCapabilities na WMS server. Je zde uvedena jen verze pro WMS 1.1.1, protože v době psaní této práce byla nejrozšířenější. Zdrojem je webový odkaz [12].

Výpis souboru capabilities_1_1_1.xml

[Přílohy]   [Výpis souboru capabilities_1_1_1.xml]
[Obsah]

Příloha D

Soubor wms_list.sql je výsledkem exportu (dump) struktury databáze wms_list databázového systému MySQL. V této struktuře jsou uloženy metadata popisující WMS server.

Dump struktury databáze wms_list (MySQL)

[Přílohy]   [Dump struktury databáze wms_list (MySQL)]
[Obsah]

Příloha E

Tanto příloha je příkladem článku informační sekce webového portálu. Popisuje význam EPSG, jeho historii a jeho použití.

Článek - informační sekce portálu

EPSG (European Petroleum Survey Group)

Příloha F

Tato příloha je příkladem článku informační sekce webového portálu. Popisuje stav podpory WMS v krajských GIS ČR.

Článek - informační sekce portálu

Podpora Web Map Service (WMS) v GIS krajů ČR

[Přílohy]   [Článek - Podpora Web Map Service (WMS) v GIS krajů ČR]
[Obsah]

Příloha G

Ukázka několika mapových kompozic vrstev WMS serverů (Náměsí Republiky v Plzni)

vrstva "Doprava" serveru HS RS



vrstva "Doprva" serveru HSRS a vrstva "ortofoto" serveru ÚHÚL



vrstva "Doprava" serveru HS RS a vrstva "VM2" mapserveru FSV, ČVUT



vrstva "Doprava" serveru HS RS a vrstva "Hlavní výkres po změně č. 278 Plzeň" GIS města Plzeň

[Přílohy]   [Ukázka několika mapových kompozic vrstev WMS serverů (Náměsí Republiky v Plzni)]
[Obsah]

Příloha H

Přiložený kompaktní disk (CD) je nedílnou součástí této práce.

Obsah CD

[Přílohy]   [Obsah CD]
[Obsah]