Kartografická vizualizace vybraných dat ČÚZK podle směrnice INSPIRE

Transkript

1 MASARYKOVA UNIVERZITA PŘÍRODOVĚDECKÁ FAKULTA GEOGRAFICKÝ ÚSTAV Kartografická vizualizace vybraných dat ČÚZK podle směrnice INSPIRE Diplomová práce Jana Morávková Vedoucí práce: doc. RNDr. Tomáš Řezník, Ph.D. BRNO 2015

2 Bibliografický záznam Autor: Název práce: Studijní program: Studijní obor: Vedoucí práce: Bc. Jana Morávková Přírodovědecká fakulta, Masarykova univerzita Geografický ústav Akademický rok: 2014/2015 Počet stran: 90 Klíčová slova: Kartografická vizualizace vybraných dat ČÚZK podle směrnice INSPIRE Geografie a kartografie Geografická kartografie a geoinformatika doc. RNDr. Tomáš Řezník, Ph.D. INSPIRE, dopravní sítě, ČÚZK, Styled Layer Descriptor, SLD, Symbology Encoding, SE, Web Map Service, WMS

3 Bibliografic Entry Author: Title of Thesis: Degree Programme: Field of Study: Supervisor: Bc. Jana Morávková Academic Year: 2014/2015 Number of Pages: 90 Keywords: Faculty of Science, Masaryk University Department of Geography Cartographical visualization of COSMC data according to the INSPIRE Directive Geography and Cartography Geographical Cartography and Geoinformatics doc. RNDr. Tomáš Řezník, Ph.D. INSPIRE, transport networks, COSMC, Styled Layer Descriptor, SLD, Symbology Encoding, SE, Web Map Service, WMS

4 Abstrakt Diplomová práce se zabývá problematikou vizualizace geografických dat sdílených prostřednictvím prohlížecích služeb (rozšířené specifikace WMS 1.3.0) služeb podle směrnice INSPIRE a navazujících dokumentů. Hlavním přínosem práce je upozornění na problémy vyplývající z podstaty použití SLD stylů, kritické zhodnocení doporučeného způsobu vizualizace na příkladu tématu dopravních sítí a také vlastní návrh alternativní vizualizace tématu ukázaný na datech ČÚZK. Navržená vizualizace je založená na exploraci typických mapových znaků používaných pro dopravní tematiku v evropských zemích a na rozdíl od datové specifikace využívá atributy a rozlišuje vizualizaci pro různá měřítka. Tato práce se zabývá problematikou kartografické vizualizace prohlížecích služeb podle datových specifikací směrnice INSPIRE. Abstract The diploma thesis deals with the issue of cartographical visualization of WMS data according to the INSPIRE Directive and related documents. The thesis highlights the issues of the use of SLD styles in general and discusses default styles according to data specifications specifically for the theme Transport Networks. Result of the work is a proposal of an alternative style for this theme, shown by an example of COSMC data. The alternative style is based on an analysis of sets of symbols, which are characteristic for other European countries. In contrast to default style it also applies attributes and takes into account different scales.

5 Masarykova univerzita Přírodovědecká fakulta ZADÁNÍ DIPLOMOVÉ PRÁCE Student: Studijní program: Studijní obor: Jana Morávková Geografie a kartografie Geografická kartografie a geoinformatika Ředitel Geografického ústavu PřF MU Vám ve smyslu Studijního a zkušebního řádu MU určuje diplomovou práci s tématem: Kartografická vizualizace vybraných dat ČÚZK podle směrnice INSPIRE Cartographical visualization of COSMC data according to the INSPIRE Directive Zásady pro vypracování: Hlavním cílem této diplomové práce (DP) je vytvoření vhodné kartografické vizualizace pomocí SLD jazyka pro vybrané INSPIRE tematiky prostorových dat Českého úřadu zeměměřického a katastrálního (ČÚZK). Pro dosažení hlavního cíle DP postupujte přes následující dílčí cíle: 1. Analyzujte kartografickou vizualizaci vybraného produktu ČÚZK. 2. Formalizujte kartografická pravidla ČÚZK v návaznosti na měřítkovou řadu. 3. Zpracujte SLD styl pro INSPIRE vizualizaci produktu ČÚZK v návaznosti na odpovídající specifikace dat. 4. Vypracujte koncept alternativní kartografické vizualizace v návaznosti na INSPIRE včetně vyjádření formou SLD. 5. Diskutujte dosažené výsledky a navazující práce.

6 Poděkování Ráda bych poděkovala především vedoucímu práce za laskavé vedení, cenné rady, ochotu i celkový velmi vstřícný a motivující přístup. Dále také svým rodičům a dalším blízkým za podporu i povzbuzení během psaní práce i celého studia. Prohlášení Prohlašuji, že jsem svoji diplomovou práci vypracovala samostatně pod vedením doc. RNDr. Tomáše Řezníka, Ph.D. a s využitím informačních zdrojů, které jsou v práci citovány. Brno, Jméno Příjmení

7 OBSAH 1 Úvod Směrnice INSPIRE Vznik infrastruktur prostorových informací Co je směrnice INSPIRE Navazující dokumenty Prováděcí pravidla Technické návody Požadavky na síťové služby Požadavky na síťové služby dle směrnice INSPIRE Požadavky dle prováděcích pravidel a technických návodů Požadavky na interoperabilitu dat Požadavky dle prováděcích pravidel a technických návodů Kartografická vizualizace dle datových specifikací Metody kartografické vizualizace Měřítková podmíněnost Slabé stránky doporučené vizualizace Nedostatečně specifický popis výchozího stylu Chybějící popis výchozího stylu Specifikace OGC Web Map Service - WMS Tenký a tlustý klient Komunikace mezi uživatelem, klientem a serverem Požadavky WMS služby a jejich parametry Výhody a nevýhody WMS služby Web Map Tile Service - WMTS Specifikace Styled Layer Descriptor a Symbology Encoding Styled Layer Descriptor Požadavky WMS služby podle specifikace Styled Layer Descriptor GetCapabilities GetMap

8 6.1.3 GetLegendGraphic Struktura SLD dokumentu Přednost při výběru vrstev a stylů Symbology Encoding Struktura Symbology Encoding Pravidla Symbolizéry Grafické proměnné Práce s SLD styly z pohledu uživatele Vytváření SLD stylu Validace SLD stylu Práce s WMS a SLD v programech ArcMap, QGIS a udig ArcMap QGIS udig Problematické aspekty SLD stylů Problémy definování velikosti objektů Definování velikostí v pixelech a metrech Rozdíly v rozlišení zobrazovacích zařízení Problémy měřítkových omezení Rozdíly ve velikosti pixelu výstupních zařízení Rozdíly v přepočtu úhlových jednotek na lineární Téma Dopravní sítě Struktura dat Geometrická reprezentace dat Dostupnost dat za Českou republiku Výchozí styly dle datové specifikace Vizualizace vrstev WMS služeb poskytovaných za Českou republiku Zhodnocení výchozích stylů dle datové specifikace Nedostatečný popis výchozích stylů Chybějící měřítková podmíněnost stylů Příliš hrubá vizualizace Motivovanost a konvenčnost mapových znaků

9 11 Vlastní návrh úpravy výchozích stylů Měřítkově podmíněná vizualizace Vizualizace založená na atributech Vizualizace založená na evropských zvyklostech Diskuze Závěr Seznam použité literatury Seznam zkratek Seznam obrázků Seznam tabulek Seznam příloh

10 1 ÚVOD Jeden z dílčích cílů směrnice INSPIRE je harmonizace dat. V současnosti jsou již dokončeny datové specifikace ke všem tématům příloh I, II a III směrnice INSPIRE. Významnou částí datových specifikací je mimo jiné popis kartografické vizualizace jednotlivých vrstev sdílených prostřednictvím prohlížecích služeb. Se sjednocenou vizualizací se otevírají možnosti bezešvého zobrazení dat od různých poskytovatelů a jejich snadné srovnávání napříč Evropskou unií. Přestože způsob vizualizace hraje klíčovou roli v předání informací uživateli, u některých témat je doporučený způsob vizualizace příliš zjednodušující. Tato práce nejprve čtenáři přibližuje, jaké požadavky na prohlížecí služby a zejména jejich vizualizaci klade směrnice INSPIRE a navazující dokumenty (kap. 2-5). Dále podrobně rozebírá možnosti vizualizace WMS vrstev pomocí SLD stylů a jazyka Symbology Encoding (kap. 6-8) a upozorňuje na některé související problematické aspekty (kap. 9). Konkrétně se pak práce zaměřuje na téma dopravních sítí. Srovnává vizualizaci dopravních sítí v produktech Českého úřadu zeměměřického a katastrálního a doporučenou vizualizaci dle příslušné datové specifikace, kde podrobně rozebírá její nevýhody (kap. 10). Zároveň si práce klade za cíl navrhnout alternativní vizualizaci tématu dopravních sítí, která by vyhověla výtkám uvedeným v předchozí kapitole (kap. 11). Tato alternativní vizualizace je zpracována graficky i formou SLD stylů. 10

11 2 SMĚRNICE INSPIRE 2.1 Vznik infrastruktur prostorových informací Díky prudkému rozvoji internetu, GIS technologií a růstu významu prostorových dat 1 se od 90. let objevuje koncept infrastruktury geografických (prostorových) informací tedy soubor technologií, pravidel, standardů a lidských zdrojů, který by umožňoval efektivní sdílení geodat [1; 2, s. 16], čímž by se zamezilo duplikacím nákladů (finančních, časových i lidských) spojených s tvorbou a údržbou geodat [2, s. 16]. Stojí tedy na myšlence, že prostorová data sbíraná pro jeden konkrétní projekt jsou většinou užitečná také pro další projekty [3] a při efektivním sdílení odpadá nutnost sbírat stejná data dvakrát. Dalším aspektem je potřeba dat sbíraných dříve, než jsou skutečně potřeba (tedy dlouhodobě sbíraná data nebo data sbíraná jen v určitých obdobích), což přináší požadavek na průběžně udržovanou a sdílenou databázi prostorových informací. To obnáší spolupráci mezi různými disciplínami a organizacemi (veřejnými i soukromými), na různých úrovních (místní, regionální, národní i globální) a strategický plán údržby geodatabáze. [3] Mezi výhody vybudování geoinformačních infrastruktur patří kromě úspor také obecný ekonomický rozvoj, zefektivnění státní správy a rozhodovacích procesů. Na úrovni Evropské unie byl zásadním dokumentem o vytvoření evropské geoinformační infrastruktury dokument GI2000 z roku 1995, který jako hlavní problémy stanovil organizační a politické překážky [2, s. 16]. První legislativní zakotvení snah o vytvoření jednotné geoinformační infrastruktury bylo dosaženo ve směrnici INSPIRE, která je vytvářena od roku Co je směrnice INSPIRE Původně byla jako INSPIRE (neboli INfrastructure for SPatial InfoRmation in Europe) označována iniciativa Evropské komise, dnes jde (v užším pojetí) přímo o označení směrnice Evropské unie 2, která tvoří legislativní rámec potřebný k vybudování infrastruktury geografických informací na úrovni Evropské unie celým názvem Směrnice 1 prostorová data (angl. spatial data) jsou data, jež přímo nebo nepřímo odkazují na určitou polohu nebo zeměpisnou oblast [4] 2 Směrnice Evropské unie (angl. directive) jsou jedním z právních předpisů Evropské unie. Směrnice zavazují členské státy, kterých se týkají (většinou všechny), aby do stanovené lhůty upravily své právní předpisy tak, 2 Směrnice Evropské unie (angl. directive) jsou jedním z právních předpisů Evropské unie. Směrnice zavazují členské státy, kterých se týkají (většinou všechny), aby do stanovené lhůty upravily své právní předpisy tak, aby bylo dosaženo cílů, které směrnice požadují. Konkrétní forma naplnění cílů směrnice je tedy na rozhodnutí každého státu. Směrnice (pokud jsou určeny všem členským státům) jsou publikovány v Úředním věstníku Evropské unie (angl. Official Journal of the European Union). [7] 11

12 Evropského parlamentu a Rady 2007/2/ES ze dne 14. března 2007 o zřízení Infrastruktury pro prostorové informace v Evropském společenství (INSPIRE). Hlavním cílem této směrnice (dále jen směrnice INSPIRE) je snadné nalezení a opětovné využívání prostorových dat (a služeb nad nimi vytvořenými a to primárně v rámci veřejné správy a samosprávy). Směrnice INSPIRE tedy navazuje na Směrnici Evropského parlamentu a Rady 2003/98/ES ze dne 17. listopadu 2003, o opakovaném použití informací veřejného sektoru (zkráceně také směrnice PSI), která byla transponována do české legislativy novelizací Zákona č. 106/1999 Sb., o svobodném přístupu k informacím. Směrnice INSPIRE má sloužit pro účely politik v oblasti životního prostředí nebo v oblastech, které životní prostředí mohou ovlivňovat. Zároveň mají být data zpřístupněná pro rozvoj služeb s přidanou hodnotou třetích stran ve prospěch jak orgánů veřejné správy i veřejnosti. [4, odst. 26] Témata, kterých se směrnice týká, jsou popsána v přílohách směrnice I, II a III a jejich soupis je uveden v tab. 1. Důvodem rozřazení do tří různých příloh jsou například odlišné termíny implementace. Směrnice INSPIRE se odkazuje na přispívání k cílům uvedeným ve Smlouvě o založení Evropského společenství [5, čl. 174 odst. 1] 3, kterými jsou: udržování, ochrana a zlepšování kvality životního prostředí, ochrana lidského zdraví, obezřetné a racionální využívání přírodních zdrojů, podpora opatření na mezinárodní úrovni, čelících regionálním a celosvětovým problémům životního prostředí. Fakticky však směrnice vznikla z iniciativ na vytvoření obecné geoinformační infrastruktury a orientace na životní prostředí spíše ve své době usnadnila posun až ke konkrétnímu legislativnímu rámci. Témata definovaná v přílohách směrnice zahrnují poměrně širokou oblast a výstupy tedy mohou přinášet výhody i nad rámec oblasti životního prostředí. Směrnice INSPIRE nevyžaduje sběr nových dat (pouze zpřístupnění již existujících) a respektuje právo duševního vlastnictví. 3 Smlouva o založení Evropského společenství byla později nahrazena Smlouvou o fungování Evropské unie, cíle politiky Evropské unie v oblasti životního prostředí však zůstaly téměř nezměněny. [14, čl. 191 odst. 1] 12

13 Tab. 1: Seznam témat prostorových dat směrnice INSPIRE Příloha I 1. Souřadnicové referenční systémy 2. Zeměpisné soustavy souřadnicových sítí 3. Zeměpisné názvy 4. Správní jednotky 5. Adresy 6. Katastrální parcely 7. Dopravní sítě 8. Vodopis 9. Chráněná území Příloha II 1. Nadmořská výška 2. Krajinný pokryv 3. Ortofotosnímky 4. Geologie Příloha III 1. Statistické jednotky 2. Budovy 3. Půda 4. Využití území 5. Lidské zdraví a bezpečnost 6. Veřejné služby a služby veřejné správy 7. Zařízení pro sledování životního prostředí 8. Výrobní a průmyslová zařízení 9. Zemědělská a akvakulturní zařízení 10. Rozložení obyvatelstva demografie 11. Správní oblasti/chráněná pásma/regulovaná území a jednotky podávající hlášení 12. Oblasti ohrožené přírodními riziky 13. Stav ovzduší 14. Zeměpisné meteorologické prvky 15. Zeměpisné oceánografické prvky 16. Mořské oblasti 17. Bioregiony 18. Stanoviště a biotopy 19. Rozložení druhů 20. Energetické zdroje 21. Nerostné suroviny 13

14 Jednotlivé národní infrastruktury mají být vybudovány a spravovány jednotlivými členskými státy na národních úrovních v souladu s Prováděcími pravidly (viz níže) tak, aby byly vzájemně slučitelné na evropské úrovni. Zároveň má být umožněno propojení dalších již vniklých iniciativ (příkladem může být mapa územního pokrytí Corine Land Cover, Informační systém evropské dopravní politiky ETIS, Evropský půdní informační systém EUSIS, program GMES dnes Copernicus, EuroGeographics, Eurostat apod.). [4, čl. 10 a 11] [6] Jako základní principy infrastruktury zakotvené ve směrnici INSPIRE se uvádí [7] [8]: data jsou sbírána a vytvářena jednou a spravována na takové úrovni, kde se tomu tak děje nejefektivněji (aby bylo možné kombinovat jednotným způsobem prostorová data pocházející z různých zdrojů a sdílet je různými uživateli) možnost bezešvě kombinovat prostorová data z různých zdrojů a sdílet je mezi mnoha uživateli a aplikacemi prostorová data jsou vytvářena na jedné úrovni státní správy a sdílena jejími dalšími úrovněmi prostorová data jsou dostupná za podmínek, které nebudou omezovat jejich rozsáhlé využití snadnější vyhledávání dostupných prostorových dat, vyhodnocení vhodnosti jejich využití pro daný účel a zpřístupnění informace, za jakých podmínek je možné tato data využít. (= zpřístupnění podmínek jejich využití) Směrnice vstoupila v platnost 15. května 2007, následující dva roky trvala tzv. fáze transpozice, během nichž byla podstata směrnice transponována do národních legislativ, a dále následuje tzv. fáze implementace tedy realizace povinností vyplývajících ze směrnice, která potrvá až do roku V České republice je směrnice ukotvena Zákonem č. 380/2009 Sb., kterým se mění zákon č. 123/1998 Sb., o právu na informace o životním prostředí, ve znění pozdějších předpisů, a zákon č. 200/1994 Sb., o zeměměřictví a o změně a doplnění některých zákonů souvisejících s jeho zavedením, ve znění pozdějších předpisů (dále jen Zákon o právu na informace o životním prostředí) 4. Další podrobnosti určuje Vyhláška č. 103/2010 o provedení změn některých ustanovení zákona o právu na informace o životním prostředí. 4 V březnu 2015 byl Zákon o právu na informace o životním prostředí opět novelizován Zákonem č. 83/2015 Sb., který nabyde účinnosti 1. září Novela neobsahuje zásadní změny, převážně byly doplněny a aktualizovány některé formulace. Byly doplněny definice některých pojmů, nově mají metadata zahrnovat i výši příp. poplatků, na geoportálu mají být uvedeny technické informace (kódy, klasifikace apod.) k zajištění souladu s technickými požadavky apod. [17] 14

15 Kontaktní organizací vůči Komisi (EU) je v České republice Ministerstvo životního prostředí, které tímto pověřilo svou resortní organizaci CENIA, českou informační agenturu životního prostředí Jakých dat a subjektů se směrnice INSPIRE týká Směrnice INSPIRE se týká souborů prostorových dat, které splňují tyto podmínky [4, čl. 4 odst. 1]: vztahují se k oblasti, ve které stát má nebo vykonává svrchovaná práva, jsou v elektronické podobě, jsou drženy: o orgánem veřejné správy, přičemž byly orgánem veřejné správy vytvořeny nebo přijaty, nebo jsou tímto orgánem spravovány nebo aktualizovány a spadají do oblasti jeho veřejných úkolů, o třetí stranou, jíž byla síť zpřístupněna v souladu s článkem 12 5, nebo jejich jménem. Povinnými poskytovateli těchto dat (tzv. povinnými subjekty) jsou [9]: správní úřady a jiné organizační složky státu a orgány územních samosprávných celků, právnické nebo fyzické osoby, které na základě zvláštních právních předpisů vykonávají v oblasti veřejné správy působnost vztahující se přímo nebo nepřímo k životnímu prostředí, právnické osoby založené, zřízené, řízené nebo pověřené subjekty uvedenými v bodech 1 a 2, jakož i fyzické osoby pověřené těmito subjekty, které na základě právních předpisů nebo dohody s těmito subjekty poskytují služby, které ovlivňují stav životního prostředí a jeho jednotlivých složek. 5 Podle tohoto článku mají mít třetí strany (např. soukromé firmy nebo neziskové organizace) na vyžádání možnost využívat síť služeb provozovanou členským státem za účelem sdílení prostorových dat a na nich založených služeb, pokud jsou v souladu se Směrnicí INSPIRE a prováděcími pravidly. 15

16 3 NAVAZUJÍCÍ DOKUMENTY Směrnice INSPIRE popisuje obecnou vizi bez ohledu na konkrétní technologická řešení. Aby byly infrastruktury vytvářené na úrovni jednotlivých zemí vzájemně kompatibilní (tj. byla zaručena jejich interoperabilita 6 a pokud možno harmonizace 7 dat a služeb na nich založených), byla postupně vydávána tzv. prováděcí pravidla (také implementační pravidla, angl. implementing rules) a technické návody (také technické specifikace, angl. technical guidelines) vycházející z platných evropských a mezinárodních norem a standardů. 3.1 Prováděcí pravidla Prováděcí pravidla se týkají oblastí metadata, specifikace dat (také datové specifikace, angl. Data Specifications), síťové služby (angl. Network Services), sdílení dat (angl. Data and Services Sharing), monitoring a reporting (angl. Monitoring and Reporting) a služby prostorových dat (angl. Spatial Data Services) a obsahují konkrétní definice toho, co je třeba pro dané oblasti splnit. Podklady připravují pro jednotlivé oblasti tzv. Návrhové týmy (angl. Drafting Teams) a poté jsou prováděcí pravidla vydávána ve formě Nařízení komise (angl. Commission Regulation) nebo Rozhodnutí komise (angl. Commission Decision). Nařízení komise i Rozhodnutí komise jsou legislativně závazná. U nových souborů prostorových dat mají členské státy povinnost zajistit soulad dat s prováděcími pravidly do dvou let od jejich přijetí, u ostatních souborů prostorových dat do sedmi let. A to buď přizpůsobením stávajících souborů, nebo prostřednictvím transformačních služeb. 3.2 Technické návody Technické návody navazují na prováděcí pravidla a popisují konkrétní technická rozhraní, jejich příklady, požadavky a normy související s prováděcími pravidly. Jsou vydávány ve formě doporučení a nejsou tedy nijak legislativně závazná. Jejich dodržování však napomáhá maximalizaci interoperability. Do budoucna se počítá s možností revizí technických návodů vzhledem k vývoji technologií, požadavků a poměru nákladů a přínosů. [10, s. 6] 6 Interoperabilita znamená možnost kombinace souborů prostorových dat a vzájemné komunikace mezi službami bez opakovaných ručních zásahů tak, aby bylo dosaženo soudržného výsledku a aby byla zvýšena přidaná hodnota souborů prostorových dat a služeb založených na prostorových datech [3]. 7 Harmonizací dat se myslí zpřístupnění prostorových dat prostřednictvím síťových služeb v takové podobě, která dovoluje bezešvé kombinování s ostatními harmonizovanými daty. A to na základě datových specifikací, které zahrnují domluvené souřadnicové systémy, klasifikace, aplikační schémata apod. [6, s. 6] 16

17 Pro tuto práci jsou nejvýznamnější prováděcí pravidla a technické návody týkající se oblastí síťové služby (více rozvedené v kap ) a specifikace dat (rozvedené v kap ). 3.3 Požadavky na síťové služby Požadavky na síťové služby dle směrnice INSPIRE Členské státy mají zřídit síť vyhledávacích, prohlížecích, stahovacích a transformačních služeb 8 [4, odst. 17]. Tyto služby mají být zpřístupněny přes geoportál INSPIRE 9, příp. i přes vlastní rozhraní (národní geoportál) [4, odst. 20]. Této práce se týkají zejména prohlížecí služby. Směrnice INSPIRE požaduje, aby prohlížecí služby umožňovaly alespoň zobrazit, procházet, přiblížit/oddálit, posouvat nebo překrývat zobrazitelné soubory prostorových dat a zobrazit vysvětlivky a jakýkoli další významný obsah metadat. [4, čl. 11 odst. 1 písm. b] Prohlížecí služby mohou být veřejnosti poskytovány bezplatně nebo za poplatek na údržbu souborů prostorových dat. Pro zpoplatněné služby musí být zřízen elektronický obchod. [4, čl. 14] Česká legislativa navíc vyžaduje i licenční smlouvu, která upravuje vztah mezi poskytovatelem dat a uživatelem dat. Její návrh je součástí metadat dané služby, vzorové licence jsou dostupné na stránkách národního geoportálu. [11, čl. 1 11c odst. 1] [12] Vydávání licencí nebo zpoplatnění využívaných dat nebo služeb na nich založených (např. pro účely sebefinancování orgánů poskytujících tato data nebo pro zajištění potřebné kvality dat) mohou orgánům veřejné správy povolit členské státy, pokud jsou poplatky udržovány v minimální výši a neodporují obecnému cíli - usnadnění sdílení dat a služeb na nich založených mezi orgány veřejné správy. Data a služby poskytnuté orgánům Evropské unie za účelem monitoringu a reportingu poplatkům nepodléhají. [4, odst. 23 a čl. 17 odst. 3] V České republice mají orgány veřejné správy, státní příspěvkové organizace a organizační složky státu zřízené pro plnění úkolů, které mají vliv na životní prostředí, k prostorovým datům vymezeným směrnicí INSPIRE (zpřístupněných na národním geoportálu) bezplatný přístup v plném rozsahu. [11, čl. 1 11c odst. 6] 8 Dodatečně byly definovány také služby prostorových dat (spadá pod ně např. internetový obchod), které jsou blíže popsány v Nařízení Komise (EU) č. 1312/2014 [53]. 9 Geoportál INSPIRE je evropský geoportál spravovaný Komisí a založený k účelům sdílení dat jako součást evropské geoinformační infrastruktury. Je dostupný z: 17

18 3.3.2 Požadavky dle prováděcích pravidel a technických návodů Poskytování síťových služeb dále upravuje Nařízení Komise (ES) č. 976/2009 ze dne 19. října 2009, kterým se provádí směrnice Evropského parlamentu a Rady 2007/2/ES, pokud jde o síťové služby (dále jen Nařízení o síťových službách). Pokyny ohledně prohlížecích služeb jsou uvedené v příloze III tohoto nařízení a dále jsou rozvedeny v Technickém návodu pro implementaci INSPIRE prohlížecích služeb - angl. Technical Guidance for the implementation of INSPIRE View Services (dále jen Technický návod pro prohlížecí služby). Nařízení o síťových službách definuje požadavky na funkce prohlížecích služeb v obecné rovině, Technický návod pro prohlížecí služby nabízí konkrétní technologická řešení a přebírá již existující specifikace organizace OGC. Těmi jsou: Web Map Service (WMS), Web Mapping Tiling Service (WMTS), Styled Layer Descriptor (SLD), Symbology Encoding (SE). Specifikace Styled Layer Descriptor a Symbology Encoding jsou převzaty beze změny. Specifikace WMS a WMTS jsou rozšířeny o další možnosti (týkají se především aspektů vícejazyčného prostředí) popsané právě v Technickém návodu pro prohlížecí služby. Tím vzniká tzv. INSPIRE profil daných specifikací. U INSPIRE služeb navíc (oproti OGC specifikacím) musí být garantována určitá kvalita z hlediska výkonnosti, kapacity a dostupnosti [13, příl. I]. Specifikacemi WMS, WMTS, SLD a SE a jejich rozšířením v rámci INSPIRE profilu se podrobněji zabývá kap Požadavky na interoperabilitu dat Požadavky dle prováděcích pravidel a technických návodů Požadavky na technické podmínky pro interoperabilitu a případně pro harmonizaci sad prostorových dat odpovídajících tématům uvedeným v příloze I až III směrnice INSPIRE (dále jen témata) jsou stanoveny v prováděcích pravidlech vydaných původně jako Nařízení Komise (EU) č. 1089/2010 (pro témata přílohy I), později novelizované jako Nařízení Komise (EU) č. 102/2011 a Nařízení Komise (EU) č. 1253/2013 (pro témata přílohy II a III) a v technických návodech pro jednotlivá témata označovaných jako datové specifikace (také specifikace dat, angl. Data Specifications). Nařízení Komise (EU) č. 1089/2010 celým názvem Nařízení Komise (EU) č. 1089/2010, kterým se provádí směrnice Evropského parlamentu a Rady 2007/2/ES, 18

19 pokud jde o interoperabilitu sad prostorových dat a služeb prostorových dat (dále jen Nařízení o interoperabilitě) mj. definuje typy prostorových objektů, jejich atributy a přidružené role a dále seznam vrstev, které mají být poskytovány prostřednictvím WMS (viz kap. 5.1). Počet vrstev jednoho tématu se pohybuje od jednoho (např. v tématu Zeměpisné názvy) do 21 (v tématu Dopravní sítě). Vrstvy musí obsahovat uvedené typy prostorových objektů a musí být zobrazeny pod uvedenými názvy. Ke každé vrstvě musí být k dispozici alespoň výchozí styl znázornění. [14, čl. 14] Datové specifikace byly vydány jako samostatné dokumenty pro všech 34 témat příloh Směrnice INSPIRE. Vytvářely je tzv. Tematické pracovní skupiny (angl. Thematic Working Groups). Všechny datové specifikace mají jednotnou strukturu. Obsahují detailní popis struktury dat prostřednictvím UML diagramů tříd (angl. UML class diagram) 10 a katalogu objektů. Dále také popis referenčních systémů (polohových, výškových, časových apod.), parametry hodnocení kvality dat, popis metadat, způsob vizualizace dat v prohlížecích službách apod. Některé datové specifikace budou dále revidovány - obsahují poznámky o nutnosti revize, doplnění, případně možných změnách a doplnění v budoucnu. S datovými specifikacemi úzce souvisí dokumenty Generic Conceptual Model (GCM; Obecný konceptuální model) a Methodology for the development of data specification (Metodika pro vývoj datových specifikací), které jim poskytují obecný rámec a popisují, jak mají být vytvářeny datové specifikace (bez ohledu na konkrétní téma). Dalším souvisejícím dokumentem je Generic Network Model (GNM; Obecný síťový model), který popisuje obecné aplikační schéma pro sítě tedy popis obecných síťových prvků a jejich vztahů. Toto obecné aplikační schéma je využitelné pro témata Dopravní sítě a Vodopis. 10 UML (Unified Modeling Language) diagramy jsou grafickým jazykem pro vytváření modelů. Jako standard byl UML přijat v roce 1997 standardizačním konsorciem Object Management Group (OMG). [17] 19

20 4 KARTOGRAFICKÁ VIZUALIZACE DLE DATOVÝCH SPECIFIKACÍ Způsob znázornění dat při sdílení prostřednictvím prohlížecích služeb je popsán v kapitole Portrayal (katalog zobrazení). Je zde opět uveden seznam vrstev a příslušných typů objektů a ke každé vrstvě navíc popis vizualizace výchozího stylu zobrazení dat. Každý poskytovatel by měl data poskytovat alespoň ve výchozím stylu, zároveň je doporučeno pro každou vrstvu poskytovat ještě další doplňkový (národní) styl. [10, s. 40]. U některých témat je kromě výchozího stylu přímo popsán také alternativní styl, případně se s jeho uveřejněním počítá do budoucna. Styly jsou popsány nejčastěji slovně, grafickou ukázkou, kódem podle Styled Layer Descriptor (problematika SLD je podrobněji probrána v kap. 6) nebo výjimečně samostatným SLD souborem. Nejčastěji kombinací více z uvedených způsobů. Výjimkou jsou témata Souřadnicové referenční systémy a Zeměpisné soustavy souřadnicových sítí, která jsou pouze referenčními tématy a popis vizualizace tedy neobsahují. Pokud vrstvy v dané datové specifikaci nemají definovaný žádný výchozí styl, pro figurální znaky 11 má být použit šedý čtverec o straně 6 pixelů, pro čárové znaky černá plná linie o šířce 1 pixel a pro areálové znaky šedá plocha ohraničená černou nepřerušovanou linií o šířce 1 pixel. [8] 4.1 Metody kartografické vizualizace U areálových znaků bývá definována barva výplně, někdy šířka a barva kontury, případně struktura (např. šrafy u tématu Geologie nebo výplň figurálními znaky hvězdami, křížky u tématu Vodopis), někdy také průhlednost. Čárové znaky jsou definovány barvou, strukturou (plná, přerušovaná nebo čerchovaná linie, příp. linie proložená speciálními znaky u tématu Geologie) a tvarem konce (např. zaoblený). Figurální znaky jsou definovány tvarem (čtverec, kruh atd.), velikostí v typografických bodech (pt) nebo pixelech (px), barvou, příp. šířkou a barvou kontury nebo složitějším piktogramovým nebo obrázkovým znakem. Další možností je vizualizace rastrových dat, u kterých jsou definovány barvy pro jednotlivé kategorie nebo rozpětí hodnot (např. u tématu Nadmořská výška), příp. dle barevných kanálů (u tématu Ortofotosnímky). Často jsou zde využívané už dříve vytvořené barevné škály (např. u tématu Krajinný pokryv je použita barevná škála dle projektu CORINE Land Cover, u tématu Geologie je použita vizualizace z projektu OneGeology- 11 V této práci jsou používány pojmy figurální, čárový a areálový, pokud jde o typ mapového znaku. Výrazy bodový, liniový a polygonový jsou používány v případě typu vrstvy nebo geometrie. 20

21 Europe a vizualizace podle Geological Time Scale 2008 Mezinárodní komise pro stratigrafii). Barvy mapových znaků jsou určeny jejich názvem, případně hexadecimálním zápisem (převážně u témat přílohy I) nebo dekadickým zápisem modelu RGB (převážně u témat přílohy II a III), příp. kódem modelu RGBA (téma Statistické jednotky). 4.2 Měřítková podmíněnost Vizualizace není rozlišená pro různé měřítkové řady, u několika málo témat je pouze uveden měřítkový rozsah, pro který je tato vizualizace vhodná (např. u témat Katastrální parcely, Nadmořská výška, nebo Zařízení pro sledování životního prostředí), případně je určení měřítkového rozsahu (dat samotných a tím pádem i vizualizace) ponecháno na poskytovateli dat prostřednictvím atributu. Někdy jsou uvedeny dvě varianty vizualizace pro objekty s odlišnými rozměry, úrovní detailu (určenou opět poskytovatelem dat prostřednictvím atributu) nebo s odlišnou formou reprezentace. Příkladem je variabilní použití figurálního, čárového nebo areálového mapového znaku u témat Vodopis, Geologie nebo Energetické zdroje. 4.3 Slabé stránky doporučené vizualizace Vizualizace často neodpovídá kartografickým zvyklostem. Například pro téma Zeměpisných názvů mají být všechny popisky zobrazeny černě, ve fontu Arial a velikosti 10 pt, umístěné ve středu geometrie. Přitom se popisky pro větší asociativnost obvykle zobrazují v různých barvách (např. vodní toky modře, nadmořská výška vrstevnic hnědě apod.) a významnější prvky se zobrazují graficky výrazněji (např. nadřazené jednotky nebo větší obce větším písmem, tučně apod.). Umístění popisku do středu dává smysl jen v případě plošných objektů, nikoliv u objektů bodových nebo liniových. Není zde řešeno mnoho dalších možností upravení textu jako jeho zakřivení, rozteč písmen, využití různých řezů písma atd. Také není řešeno riziko kolizí s dalšími objekty nebo jinými popisky. Často jsou používány neobvyklé barvy mapových znaků nebo neobvyklé barevné škály (např. u témat Dopravní sítě, Využití území) s důsledkem špatné asociativnosti s reálnými objekty. Také není uvažováno současné zobrazování vrstev z různých témat. Přitom se dá očekávat, že uživatele budou zajímat vzájemné vztahy objektů a informace z více témat zároveň. Při zobrazování vrstev z více témat tedy mohou některé znaky splývat a bude docházet ke konfliktům (překryv významných prvků, křížení linií, nevhodné pořadí vrstev apod.). Dle [8, s. 99] toto v současnosti není prioritou a specifikace se tedy vizualizací zabývají pouze z hlediska konkrétního tématu. 21

22 Podrobněji jsou nedostatky doporučené vizualizace rozebrány na příkladu tématu Dopravních sítí v kap Nedostatečně specifický popis výchozího stylu U tématu Geologie jsou některé složitější znaky (např. několik areálových znaků s nepravidelnou strukturou nebo složené čárové znaky) znázorněny pouze graficky bez přesnějšího popisu a parametrů a proto budou pravděpodobně každým poskytovatelem znázorněny odlišně, stejně tak chybí přesné parametry znaků u některých vrstev tématu Stanoviště a biotopy a tématu Rozložení druhů, a také u celého tématu Nerostné suroviny a Zeměpisné oceánografické prvky Chybějící popis výchozího stylu U některých vrstev některých témat, případně u některých celých témat chybí popis vizualizace úplně. To se týká vrstvy Environmental Management Facility Installation Style tématu Veřejné služby a služby veřejné správy a tématu Mořské oblasti U některých témat jsou uvedena pouze obecná doporučení například u vrstvy Health statistical data tématu Lidské zdraví a bezpečnost (jedná se o znázornění statistických dat) je pouze doporučeno používat obvyklé metody tematického mapování a je zde navrhnuto poskytnout na INSPIRE geoportálu nástroj pro jednoduché online tematické mapování. V tématech Stav ovzduší a Zeměpisné meteorologické prvky nejsou specifikovány žádné vrstvy ani způsob vizualizace s upozorněním, že nejvhodnější vizualizace záleží na způsobu využití a vizualizaci dalších zobrazených vrstev (což je ovšem zřejmé a platí to i u všech ostatních témat). Je zde jediné doporučení, které doporučuje dodržovat standardy WMO, pokud je služba určena meteorologickým expertům. Někdy nejsou uvedena vizualizační pravidla, pouze příklady vizualizace z konkrétních projektů jako příklady dobré praxe, případně jsou doplněny dalšími obecnými doporučeními. Tak je tomu u tématu Rozložení obyvatelstva demografie, kde jsou uvedeny příklady a obecná doporučení pro vytváření vlastní vizualizace, u většiny vrstev tématu Oblasti ohrožené přírodními riziky, kde jsou opět uvedeny pouze příklady (např. schéma používané ve Francii pro povodňové ohrožení nebo záplavové ohrožení pobřeží v Nizozemsku) a obecná doporučení (např. užití maximálně pěti tříd u kvantitativních kategorií, použití šrafury, ). Stejná situace je u tématu Stanoviště a biotopy (pouze příklad včetně jeho SLD zápisu) a u rastrové formy tématu Energetické zdroje. U tématu Bioregiony může být použito vlastní barevné schéma. Někdy je vizualizační styl popsán dostatečně podrobně, ale je uvedeno více jeho alternativ (i u výchozího stylu) např. u tématu Rozložení druhů. 22

23 Z výše uvedeného vyplývá, že ani po splnění všech požadavků současných datových specifikací u mnohých témat (zejména přílohy III) výsledkem nebudou plně harmonizovaná data. 23

24 5 SPECIFIKACE OGC 5.1 Web Map Service - WMS Web Map Service (WMS), v překladu webová mapová služba, je jedním z typů prohlížecích služeb a v obecné rovině jedním ze způsobů zpřístupnění geografických dat prostřednictvím internetu. WMS jako standard byl vytvořen a vyvíjen od roku 1998 organizací Open Geospatial Consortium 12, nejaktuálnější verze je nyní [15] Jako mezinárodní norma byl standard WMS přijat v roce 2005 organizací International Organization for Standardization (ISO) pod označením ISO Geografická informace: Rozhraní webového mapového serveru. Jde tedy o totožné dokumenty. Dle Technického návodu pro prohlížecí služby (viz kap ) je doporučeno používání verze 1.3.0, ale je možné používat i starší verzi [10, s. 10]. Výstupními formáty služby jsou buď grafické formáty PNG, JPEG, TIFF, SVG aj. (při zaslaní mapové vrstvy) nebo text ve formátu XML (při zaslání metadat a dalších informací). Uživatel tedy nemá k dispozici samotnou geometrii prvků, služba je však interaktivní a uživatel může například zapínat a vypínat předpřipravené vrstvy a překryvem je kombinovat do výsledné kompozice. Samotná georeferencovaná data (např. ve formátu Shapefile, GeoTIFF nebo jako součást relační databáze) jsou umístěná na úložišti mapového serveru a v nastavení serveru jsou definovány možnosti WMS. Uživatel má k datům přístup prostřednictvím tenkého nebo tlustého klienta Tenký a tlustý klient Tenkým klientem (angl. thin client) je například webový prohlížeč, který pouze komunikuje s mapovým serverem a zobrazuje výsledná rastrová data, ale neprovádí s daty žádné další vlastní operace a výpočty. Naopak tlustým klientem (angl. thick client) je například software instalovaný na počítači nebo přenosném zařízení, který je schopný dále samostatně zpracovávat přijatá data. Prostřednictvím tenkého klienta uživatel například žádá server o poskytnutí výstupu v preferovaném souřadném systému, při použití tlustého klienta může být obdržený výstup transformován do požadovaného souřadného systému vlastním přepočtem softwaru. Přesné definice tenkého a tlustého klienta se u různých autorů liší. Dle [16] tenký klient umožňuje zobrazovat pouze standardní HTML kód a standardní rastrové formáty pro 12 Open Geospatial Consortium (OGC) je mezinárodní uskupení firem, vládních agentur a univerzit, jehož cílem je vytváření, rozvoj a implementace otevřených standardů pro geoprostorová data, služby a jejich sdílení (dalšími standardy vytvořenými OGC jsou například GML, KML nebo CSW). 24

25 HTML a mapový server musí pro takového klienta generovat nejen rastrové obrázky (mapové pole), ale i celé uživatelské prostředí pro prezentaci, jako jsou formuláře a ovládací nástroje. Oproti tomu tlustý klient (mimo desktopový software např. také webový prohlížeč rozšířený o plug-in nebo Java applet) umožňuje zobrazovat nejen rastrové formáty pro HTML, ale i různé vektorové formáty, eventuelně i jiné rastrové formáty, může fungovat i bez mapového serveru a uživatelské prostředí definuje samotný klient [16] Komunikace mezi uživatelem, klientem a serverem Klient využívá při komunikaci se serverem dotazovací metody GET a POST protokolu Hyper Text Transfer Protocol (HTTP) [15, s ]. Při každé změně zobrazené oblasti (posun, přiblížení mapy), příp. jiných parametrů (export mapy v podrobnějším rozlišení apod.) zasílá klient serveru nový požadavek a server zasílá novou odpověď. Proto je překreslování mapy poměrně pomalé. Zjednodušené schéma komunikace mezi uživatelem, klientem a mapovým serverem podle specifikace WMS je znázorněno na obr. 1. Obr. 1: Zjednodušené schéma komunikace mezi uživatelem, klientem a mapovým serverem podle specifikace WMS, upraveno podle [17] Požadavky WMS služby a jejich parametry WMS služba je obsluhována základními požadavky (operacemi), které uživatel zasílá serveru. Tyto operace jsou popsány v příslušné OGC specifikaci, informace o jejich rozšíření na INSPIRE profil jsou uvedeny obecně v Nařízení o síťových službách a konkrétně pak vtechnickém návodu pro prohlížecí služby. Povinnými operacemi jsou dle OGC specifikace GetCapabilities a GetMap. Požadavkem GetCapabilities uživatel žádá zobrazení metadat a vlastností dané služby (nejčastěji ve formátu XML) potřebných pro specifikování požadavku GetMap. 25

26 Požadavkem GetMap uživatel zasílá požadavek na zobrazení samotné mapy. INSPIRE profil možnosti těchto požadavků rozšiřuje, ale zůstává s nimi zpětně kompatibilní. OGC specifikace navíc definuje volitelnou operaci GetFeatureInfo, která uživateli vrátí XML soubor s atributy prvku vyskytujícím se na mapě na určitých souřadnicích. Tato operace není v rámci INSPIRE profilu požadována a tedy ani blíže popsána. Poskytovatel dat ji ovšem i tak podporovat může. INSPIRE profil naopak oproti OGC specifikaci přímo požaduje podporu operace Link View Service, která umožňuje kaskádování serverů a může např. zpřístupnit uživateli službu třetí strany přes národní službu členského státu [10, s ]. Vztah mezi operacemi WMS služby (a jejich označením) ve specifikaci OGC a v dokumentech INSPIRE je znázorněn v tab. 2. Tab. 2: Vztah mezi operacemi WMS služby ve specifikaci OGC a v dokumentech INSPIRE OGC specifikace WMS (ISO 19128) dokumentace INSPIRE GetCapabilities (povinné) Get View Service Metadata (povinné) GetMap (povinné) Get Map (povinné) GetFeatureInfo (volitelné) - - Link View Service (povinné) Každý z těchto požadavků obsahuje tzv. parametry, které jej dále upřesňují. Některé parametry jsou stanoveny jako povinné (jsou nezbytné k základnímu specifikování požadavku), některé jsou pouze volitelné (nabízí tedy další funkcionalitu, která může být uživateli užitečná, ale není zásadní pro samotné zaslání odezvy) GetCapabilities Povinnými parametry požadavku GetCapabilities je pouze SERVICE a REQUEST. Parametry SERVICE označuje typ služby v tomto případě je to vždy WMS, parametr REQUEST značí typ požadavku v tomto případě vždy GetCapabilities ). Dle [10, s. 17] jsou možnosti v INSPIRE profilu rozšířeny o nepovinný parametr LANGUAGE (kód preferovaného jazyka). Odezvou jsou mimo jiné informace o dostupných vrstvách, seznam referenčních souřadnicových systémů, v nichž je vrstva dostupná a také seznam nabízených stylů pro danou vrstvu. Ukázka nejjednoduššího požadavku GetCapabilities a odezvy serveru je zobrazená v tab

27 Tab. 3: Ukázka požadavku GetCapabilities a odezvy serveru požadavek GetCapabilities TN/WMService.aspx?SERVICE=WMS& REQUEST=GetCapabilities část odezvy serveru V odezvě GetCapabilities je uvedená informace o jazyce, který je používaný jako výchozí a o dalších podporovaných jazycích. Pokud je některý z podporovaných jazyků zadán v rámci požadavku GetCapabilities (viz výše), pak je v tomto jazyce zobrazen text odezvy GetCapabilities, legenda a také případná chybová hlášení. [10, s. 18, 54] Všechny dostupné styly je možné nalézt v elementech <Style>, které obsahují povinné podřazené elementy <Title> (název srozumitelný pro člověka) a <Name> (unikátní identifikátor používaný v požadavku GetMap). Dále může obsahovat volitelný element <Abstract> (stručný popis stylu). Element <LegendURL> (obsahuje odkaz umístění obrázku s legendou stylu) je v případě OGC specifikace uváděn jako volitelný [15, s. 26], podle směrnice INSPIRE je však obecně zobrazení legendy (blíže neurčeným způsobem) povinné 13 [4, čl. 11 odst. 1 písm. b]. Doporučované formáty legendy jsou PNG nebo GIF [10, s. 41]. Ukázka elementu <Style> jedné vrstvy WMS je na obr Jako druhá alternativa zobrazení legendy se nabízí požadavek GetLegendGraphic (viz kap ) 27

28 Obr. 2: Ukázka elementu <Style> z části XML souboru zaslaného jako odezvu na požadavek GetCapabilities Ostatní metadata uváděná v odezvě GetCapabilities nejsou v rámci této práce významná, obecně však INSPIRE profil požadavky specifikace OGC o několik položek rozšiřuje GetMap Mezi povinné parametry požadavku GetMap patří LAYERS (tedy seznam požadovaných vrstev), BBOX (souřadnice levého spodního a pravého horního rohu ohraničujícího obdélníku požadované oblasti), CRS - ve starší verzi specifikace také SRS (souřadnicový systém ve formě EPSG kódu 14 ), WIDTH a HEIGHT (šířka a výška požadovaného výstupu zadaná v pixelech), FORMAT (požadovaný formát výstupu) a také STYLES (zvolené styly vizualizace jednotlivých vrstev zapsané jako unikátní identifikátory stylů uvedené v odezvě požadavku GetCapabilities oddělené čárkami). Podle Technického návodu pro prohlížecí služby má být vrstva poskytnuta, i pokud je povinný parametr STYLES ponechán prázdný pak má být automaticky použit výchozí styl, který má být označený jako <inspire_common:default>). [10, s. 40, 48] Mezi volitelné parametry požadavku patří např. TRANSPARENT (udává, má-li být pozadí výstupu průhledné nebo ne) a BGCOLOR (barva pozadí vrstvy). Podle Technického návodu pro prohlížecí služby musí být výstupy (mapové vrstvy zaslané jako odpověď serveru) dostupné minimálně ve formátu PNG nebo GIF bez komprimace a v referenčních souřadnicových systémech uvedených v [18] nebo [10, s. 39, 48]. 14 Databáze s názvem Geodetic Parametr Set obsahuje parametry souřadnicových systémů a transformací. Je dostupná na adrese Původně byla sestavovaná organizací European Petroleum Survey Group (odtud označení EPSG), po zániku v roce 2005 ji převzala asociace International Association of Oil & Gas producers (IOGP). 28

29 Ukázka nejjednoduššího požadavku GetMap a odezvy serveru je zobrazená v tab. 4. Tab. 4: Ukázka požadavku GetMap a odezvy serveru požadavek GetCapabilities TN/WMService.aspx?SERVICE=WMS& VERSION=1.3.0&REQUEST=GetMap& LAYERS=TN.RoadTransportNetwork.Ro adlink&styles=default&crs=epsg: 3034&BBOX= , , , &WIDTH=600& HEIGHT=600&FORMAT=image/png odezva serveru Výhody a nevýhody WMS služby Mezi výhody WMS služeb patří možnost snadného zpřístupnění dat širokému okruhu uživatelů, správa prostorových dat na jednom místě, interoperabilita, možnost kombinace prostorových dat od více různých poskytovatelů, kaskádování serverů a poměrně velká míra kontroly poskytovatele nad podobou výstupu. Tyto výhody do velké míry vyhovují potřebám a cílům iniciativy INSPIRE, proto WMS služby patří k základním prostředkům sloužící k naplnění cílů směrnice. Mezi nevýhody pak patří závislost na dostupnosti a kvalitě internetového připojení, relativně pomalé vykreslování dat a velmi omezené možnosti manipulace s daty ze strany uživatele (není možné provádět výběry, analýzy apod.). 5.2 Web Map Tile Service - WMTS Dle Nařízení o síťových službách je pro naplnění požadavku zprostředkování prohlížecích služeb doporučeno používání WMS, je ale možné využívat i Web Map Tile Service (WMTS) [13, s. 10]. WMTS je dalším typem prohlížecí služby standardizované OGC (v aktuální verzi 1.0.0). WMTS umožňuje zobrazení předem vygenerovaných dlaždic, které byly uloženy jako jednotlivé rastrové soubory. Tyto dlaždice jsou klientovi serverem zasílány na základě požadovaného mapového výřezu (BBOXu a měřítka). Na podobném principu fungují také 29

30 mapové portály Google Maps a Mapy.cz [19]. Tato služba tedy umožňuje rychlejší vykreslování mapy než služba WMS a nemá takové nároky na webový server. Na druhou stranu nedovoluje vypínání a zapínání jednotlivých dílčích vrstev ze strany klienta ani uživateli neumožňuje vizualizaci pomocí vlastních stylů (viz dále). Míra kontroly poskytovatele nad podobou výstupu je tedy ještě vyšší než u WMS. WMTS je výhodné využívat u dlouho neměnných map (např. podkladové mapy, letecké snímky apod.), protože při každé aktualizaci je nutné opětovné generování všech dlaždic a opětovné umístění na serverové úložiště. [19] [20] 5.3 Specifikace Styled Layer Descriptor a Symbology Encoding Symbology Encoding (SE) a Styled Layer Descriptor (SLD) jsou dalšími standardy OGC, které rozšiřují možnosti některých výše uvedených služeb. Aktuálními verzemi jsou u obou specifikací verze Specifikace Styled Layer Descriptor rozšiřuje možnosti WMS služeb a dovoluje uživateli vlastní volbu způsobu vizualizace zobrazené mapové vrstvy. Tedy např. že linie představující komunikaci má být vykreslena červenou barvou a s šířkou 2 pixely. K tomu je zapotřebí vizualizační jazyk, kterému by rozuměl server i klient tím je Symbology Encoding. Symbology Encoding se vztahuje k popisu vizualizace vektorových a rastrových dat (u rastrových dat jsou ovšem možnosti změny vzhledu vykreslené vrstvy pouze omezené) i textových popisků. Způsob vizualizace podle pravidel Symbology Encoding se zapisuje jazykem XML. Buď je tedy styl vizualizace definován přímo poskytovatelem dat a uložený na straně serveru a uživatel jej pouze uvede v parametru STYLES požadavku GetMap (případně poskytovatel může vizualizačních stylů poskytovat více a pak si uživatel zvolí nejvhodnější z nich) nebo si uživatel definuje vlastní styl, zapíše jej ve formátu XML a přidá k požadavku GetMap. Server pak tento styl aplikuje na data ze svého úložiště a zašle obraz zpět klientovi. V rámci specifikace Styled Layer Descriptor je popsána komunikace se serverem a počáteční elementy XML dokumentu, které zodpovídají za správné spárování vrstev a stylů. V rámci Symbology Encoding jsou popsány elementy XML dokumentu, které určují samotnou vizualizaci (styl) dané vrstvy. Specifikace Styled Layer Descriptor se týká pouze WMS služeb, principy specifikace Symbology Encoding lze aplikovat i na jiné služby (aktuálně na výše zmíněné Web Feature Service a Web Coverage Service). V původní verzi specifikace Styled Layer Descriptor 1.0 z roku 2002 byl standard SE součástí společné specifikace SLD, později byly oba standardy rozděleny do dvou samostatných specifikací právě z důvodu, aby koncept Symbology Encoding bylo možné využít i pro jiné služby než WMS. 30

31 6 STYLED LAYER DESCRIPTOR 6.1 Požadavky WMS služby podle specifikace Styled Layer Descriptor V této části je stručně popsán způsob komunikace s mapovým serverem tedy rozdíly v dotazování serveru při použití SLD oproti samotné specifikaci WMS GetCapabilities Požadavek GetCapabilities ze strany uživatele je stále stejný, v rámci souboru XML s odpovědí zaslanou serverem však přibudou další informace. Např. na obr. 3 element SupportSLD uvádí informaci, že WMS služba podporuje funkce popsané ve specifikaci SLD, element UserStyle uvádí, zda je uživateli umožněno použít vlastní vizualizační styl. [21, s. 10] Obr. 3: Ukázka odezvy na požadavek GetCapabilities WMS služby INSPIRE prohlížecí služba pro téma Dopravní sítě (TN) poskytované ZÚ GetMap Vlastní vizualizaci (uživatelský styl) je z pohledu uživatele možné připojit k WMS vrstvě jedním ze tří možných způsobů. První dva využívají HTTP metodu GET, kdy je dotaz kódován jako URL. V prvním případě uživatel nahraje vytvořený styl ve formátu XML na internetové úložiště a do GetMap požadavku doplní parametr SLD s odkazem na uložený dokument. 31

32 Uložený soubor pak samozřejmě musí být pro server volně dostupný. Příklad takového požadavku je uveden zde: REQUEST=GetMap&LAYERS=Road_Link&CRS=EPSG:3035&BBOX= , , , &WIDTH=450&HEIGHT=300&FORMAT=image/png& SLD= Dalším způsobem je použití obdobného parametru SLD_BODY, kdy je celý XML kód popisující vizualizaci uveden přímo v rámci tohoto parametru. Celý dotaz je pak tedy obvykle velmi dlouhý (může tedy např. překročit limit některých prohlížečů) a musí být zapsán v souladu s URL kódováním. Výhodou však je, že není nutné nahrávat styl na internet. Třetím způsobem je využití metody POST, kdy je celý požadavek GetMap včetně vloženého stylu kódován v XML. [21, s ] Povinným parametrem požadavku GetMap je SLD_VERSION (verze SLD specifikace např ). Parametr LAYERS je dle této specifikace nepovinným (odlišně oproti specifikaci WMS 1.3.0) a pokud v požadavku není uveden, pak jsou v odezvě automaticky poskytnuty všechny vrstvy jmenované v uživatelském stylu. [21, s ] Ostatní parametry zůstávají stejné dle WMS Odezvou na požadavek GetMap je grafický soubor s geografickými daty vizualizovanými dle zvoleného stylu nebo dle vlastního uživatelského stylu. V případě kaskádování serverů specifikace umožňuje definovat vizualizační styl i WMS vrstvy, která používá data z připojené WFS nebo WCS 15. K tomu slouží volitelné parametry Remote_ows_type (určuje typ služby WFS nebo WCS) a Remote_ows_url (adresa služby) požadavku GetMap. [21, s. 6] GetLegendGraphic Dalším volitelným požadavkem je GetLegendGraphic, který plní obdobnou funkci jako ULR v elementu <LegendURL> v odezvě na GetCapabilities. Jako odezva na tento 15 Web Feature Service (WFS) umožňuje sdílení vektorových dat ve formátu GML, nejedná se tedy o pouhý obraz geografických dat, jako je tomu u WMS služby, ale o data samotná, která je možné editovat a pracovat s jejich atributy. Web Coverage Service (WCS) umožňuje přenos rastrových i vektorových dat v původním formátu. Tato data tedy lze dále zpracovávat (ne jen zobrazit jako u WMS). Díky parametru TIME služba umožňuje sdílení informací o změnách prostorových dat v čase. Typickým využitím WCS je např. zpracování satelitních dat. WFS i WCS jsou ve směrnici INSPIRE označovány jako služby stahování dat. 32

33 požadavek by uživateli měla být zobrazena legenda tedy mapový znak ve formě obrázku a textový popis daného prvku. Tuto legendu může generovat i klient na základě SLD a aktuálního měřítka. Takto vygenerovaná legenda však nemusí být plně v souladu s mapou, protože klient a server mohou používat jiné způsoby renderování obrazu. Parametry požadavku jsou obdobné jako u požadavku GetMap. Alternativně může legendu zobrazit přímo server podobně jako u LegendURL [21, s ]. 6.2 Struktura SLD dokumentu V této části je stručně popsána struktura XML dokumentu, definujícího vizualizaci WMS vrstvy podle specifikace SLD Na prvním řádku dokumentu je uvedená XML deklarace (definuje použitou verzi XML a použitou znakovou sadu): <?xml version="1.0" encoding="iso "?> Kořenovým elementem je element <StyledLayerDescriptor>, který obsahuje informace o použité verzi specifikace, o umístění a názvu souboru daného XML schématu (XSD) a také deklarace jmenných prostorů. Vypadá zpravidla takto: <StyledLayerDescriptor version="1.1.0" xsi:schemalocation=" StyledLayerDescriptor.xsd" xmlns=" xmlns:sld=" xmlns:se=" xmlns:ogc=" xmlns:xlink=" xmlns:xsi=" </StyledLayerDescriptor> Jmenné prostory (angl. namespace) slouží k rozlišení elementů (příp. atributů) z různých sad, aby se nestalo, že dva různé elementy budou mít shodná jména. Jmenný prostor je deklarován pomocí atributu skládajícího se z řetězce xmlns, dvojtečky a tzv. prefixu jmenného prostoru (např. sld nebo ogc), kterým je dále zastupován. Hodnotou atributu je URI adresa, na které se nemusí nacházet žádný obsah, slouží pouze jako identifikátor. Např.: xmlns:sld=" 33

34 Název elementu, který patří k určitému jmennému prostoru, se pak skládá ze dvou částí prefixu a lokálního názvu oddělených dvojtečkou. Např.: <sld:namedlayer>. Pokud se název atributu skládá pouze s textového řetězce xmlns, pak jde o implicitní jmenný prostor: xmlns=" Název elementu je pak zapisován bez prefixu: <NamedLayer>. U SLD dokumentů je prefix sld často vynecháván a daný jmenný prostor je brán jako implicitní. V INSPIRE datových specifikacích je tento prefix používán, proto je tomu tak i u souborů v příl. 6. Používání jmenných prostorů je popsáno ve standardu Namespaces in XML publikovaného v roce 1999 konsorciem W3C (World Wide Web Consortium) [22]. Kořenový element <StyledLayedrDescriptor> obsahuje podřízené elementy <NamedLayer>, případně <UserLayer>. Element <NamedLayer> ohraničuje styl, který se týká jedné vrstvy. Jeho podřízený element <Name> funguje jako identifikátor a určuje, které vrstvy se daný styl týká. Obsah elementu <Name> tedy musí být totožný s názvem vrstvy v parametru LAYERS požadavku GetMap. Tento název vrstvy je také uveden ve stejnojmenném elementu (v nadřízeném elementu <Layer>) v GetCapabilities: Pokud tedy chceme zobrazit více vrstev v rámci jednoho GetMap požadavku, pak styl pro každou z těchto vrstev uvedeme v SLD dokumentu v rámci samostatného elementu <NamedLayer>. Element <NamedLayer> slouží k výběru jedné z vrstev, kterou poskytuje server. Pokud bychom chtěli v rámci jednoho požadavku připojit také vlastní vrstvu - buď prostřednictvím WFS nebo WCS, případně nadefinovat vlastní geometrii objektu dle 34

35 syntaxe GML (např. pro zvýraznění jednoho konkrétního objektu), použijeme místo něj element <UserLayer>. [21, s. 30] Element <NamedLayer> obsahuje podelementy <NamedStyle> nebo <UserStyle>. Element <NamedStyle> umožňuje výběr jednoho ze stylů nabízeného WMS službou, element <UserStyle> pak umožňuje definovat vlastní styl prostřednictvím Symbology Encoding. Výše uvedené elementy tedy umožňují také definování komplexního stylu v případě, že je třeba např. kombinovat vrstvy z různých zdrojů a navíc částečně využít vizualizaci nabízenou WMS serverem a částečně si definovat vlastní. V případě této práce je třeba vždy pouze definovat styl k nabízené vrstvě, a proto jsou používány pouze elementy <NamedLayer> a jemu podřízený <UserStyle>. Další podřízené elementy už jsou součástí specifikace SE popsané v následující kapitole. 6.3 Přednost při výběru vrstev a stylů Při výběru vrstev a stylů mají v případě kolizního požadavku přednost vrstvy a styly nadefinované uživatelem (před styly poskytovanými serverem). Na základě požadavku GetMap jsou zobrazeny všechny vrstvy vyjmenované v parametru LAYERS. Pokud tento parametr uveden není, ale je uveden parametr SLD, příp. SLD_BODY (a zároveň parametr SLD_VERSION), pak jsou zobrazeny všechny vrstvy vypsané v rámci SLD. V případě uvedení parametrů LAYERS, STYLE i SLD (příp. SLD_BODY), je podle názvu vrstvy nejdříve vyhledáván odpovídající uživatelský styl (v připojeném SLD) a až pokud není nalezen, tak je použit styl poskytnutý ze strany serveru. Obdobně pokud není použit parametr STYLE nebo je jeho hodnota default a v SLD je daný styl označen jako defaultní (pomocí elementu <IsDefault> s hodnotou 1), pak má tento styl přednost před defaultním stylem serveru. [21, s ] Co se týče výsledného pořadí vrstev, obecně na různých úrovních SLD dokumentů platí, že čím výše je daný element (<NamedLayer>, <Rule> apod.) zapsaný v SLD kódu, tím výše se také zobrazuje při vykreslování objektů (obsah prvního elementu se tedy vykreslí jako nejhornější vrstva a překryje všechny ostatní). 35

36 7 SYMBOLOGY ENCODING V rámci elementů ze Symbology Encoding je popsán samotný styl zobrazení jednotlivých vrstev. Specifikace Symbology Encoding tedy popisuje další možné vnořené elementy a jejich interpretaci. 7.1 Struktura Symbology Encoding Každý element <UserStyle> z SLD obsahuje kořenový element SE - <FeatureTypeStyle> nebo <CoverageStyle> v závislosti na typu dat, kterému má být styl přiřazen. Pro účely vizualizace vrstev WMS služby slouží element <FeatureTypeStyle>. Nepovinným atributem <FeatureTypeStyle> je version (číslo verze použité SE specifikace). Podřízenými volitelnými elementy <FeatureTypeStyle> jsou zejména <Name> (název), Description (popis), <FeatureTypeName> (název typu objektu, ke kterému se má daný styl vztahovat) a <Rule> (popisují vykreslení vrstvy na základě definovaných podmínek). Co se týče elementu <FeatureTypeName>, v datových specifikacích některých témat je použit pouze název typu objektu (např. CadastralParcel), u některých témat název balíčku (angl. package) i typu objektu oddělené tečkou (např. Network.WatercourseLink), u tématu dopravních sítí je použit název balíčku a typu objektu oddělený dvojtečkou (např. Network:Node), případně zkratka tématu a typu objektu (např. TN:RoadLink). Oddělení tečkou se jeví vhodnější, protože většina validátorů považuje dvojtečku za součást prefixu a výraz tedy označuje jako chybu Pravidla Pravidla elementu <Rule> mohou být aplikována na základě měřítkových omezení (podřízené elementy <MinScaleDenominator> a <MaxScaleDenominator> více viz kap. 9.2) a na základě filtrů (element <Filter>), které jsou nejčastěji aplikovány na hodnoty atributů. Syntaxe elementu <Filter> se řídí specifikací Filter Encoding [23] a umožňuje výběr na základě srovnávacích, prostorových a logických operátorů. Použité podmínky se mohou vzájemně překrývat a jsou aplikovány v pořadí, v jakém jsou uvedeny v rámci kódu. Pokud je v rámci jednoho pravidla uvedeno více filtrů (příp. i s měřítkovým omezením), pak je pravidlo aplikováno pouze na objekty, které splňují všechny tyto podmínky zároveň. [24, s. 13] 36

37 Element <ElseFilter> umožňuje určit, podle jakého pravidla budou vizualizovány zbývající objekty, na které se nevztahuje žádný definovaný filtr. V rámci jednoho elementu <UserStyle> by mělo být pouze jedno pravidlo <ElseFilter>. Pokud element <Rule> neobsahuje žádný element měřítkového omezení ani filtr, pak je styl aplikovaný na všechny objekty Symbolizéry Styl samotný je pak popsaný v rámci tzv. symbolizérů (angl. symbolizers) elementů <LineSymbolizer>, <PolygonSymbolizer>, <PointSymbolizer>, <TextSymbolizer> nebo <RasterSymbolizer>. Výběr symbolizérů záleží na charakteru zdrojových dat (formátu a typu geometrie). Např. pokud je zdrojem dat uložených na serverovém úložišti rastrový soubor, pak lze na vrstvu aplikovat pouze element <RasterSymbolizer> a není tedy možné nastavit vlastnosti jednotlivých objektů (např. šířku a barvu linií). Pokud je zdrojem dat liniová vrstva v kompatibilním vektorovém formátu, pak toto nastavit lze pomocí elementu <LineSymbolizer>. V obou případech však finálním výstupem (odpovědí serveru) může být mapová kresba ve formátu JPEG a rozdílnost zdrojových dat tedy na první pohled nemusí být zřejmá. U vektorových dat je možné použít jiný typ symbolizéru, než který odpovídá danému typu geometrie. V případě, že je použit element <LineSymbolizer> pro polygonovou vrstvu, pak jsou vykresleny pouze uzavřené obrysy polygonů s nastavenými vlastnostmi čárového znaku [24, s. 16]. Pokud je pro polygonovou nebo liniovou vrstvu použit element <PointSymbolizer>, pak je vykreslen pouze centroid (nebo jiný reprezentativní bod) dané geometrie s vlastnostmi figurálního znaku [24, s. 21]. Nahrazení polygonů jednotlivými figurálními znaky může být výhodné při zobrazování vrstev v malých měřítcích jako forma geometrické generalizace. Pro jednotlivé symbolizéry je možné nadefinovat grafické proměnné jako je tvar, barva nebo průhlednost. Tyto vlastnosti jsou odvozeny ze standardů SVG a CSS2 konsorcia W3C (World Wide Web Consortium). Dřívější parametr <CssParameter> (používaný v rámci společné specifikace SLD 1.0) byl ve specifikaci SE zaměněn za parametr <SvgParameter>. Jednotlivé parametry SVG jsou zapsány jako hodnoty atributu name (elementu <SvgParameter>) a hodnoty SVG parametrů jsou zapsány jako obsah tohoto elementu. Např. <se:svgparameter name="stroke">#008000</se:svgparameter>, <se:svgparameter name="stroke-width">3</se:svgparameter>. 37

38 Každý symbolizér může obsahovat volitelný element <Geometry> a jemu podřízený <PropertyName> značící název atributu geometrie, která má být vykreslena (u tématu Dopravních sítí je vždy pouze jeden možný) Grafické proměnné LineSymbolizer Element <LineSymbolizer> obsahuje podřízený element <Stroke> nebo <PerpendicularOffset>. V rámci elementu <Stroke> a jemu podřízeného <SvgParameter> je u čárových znaků možné nadefinovat barvu (hodnota atributu name= stroke ), průhlednost ( strokeopacity ), šířku ( stroke-width ), typ vykreslení rohů zalomených linií ( stroke-linejoin ), typ zakončení linie ( stroke-linecap ) a přerušovanou linii ( stroke-dasharray definuje délku linie a přerušení, stroke-dashoffset definuje začáteční pozici linie vzhledem k přerušení). Při použití <GraphicStroke> (místo <SvgParameter>) je možné vytvoření linie z opakujících se figurálních znaků, při použití <GraphicFill> (s podřízenými elementy stejnými jako u figurálních znaků) pak vyplnění linie opakujícími se znaky. Odsazení linie od geometrie je možné pomocí výše zmíněného elementu <PerpendicularOffset> [24, s ] PolygonSybolizer U areálových znaků je možné v rámci elementů <Fill> a podřízeného <SvgParameter> opět definovat barvu ( fill ) a průhlednost ( fill-opacity ). A obdobně i vyplnění plochy opakujícím se znakem (vnořený element <GraphicFill>). Možnosti nastavení kontury areálového znaku ohraničeného konturou jsou stejné jako možnosti nastavení čárových znaků elementem <Stroke>. Zmenšení nebo zvětšení vykreslené plochy oproti geometrii zajišťuje element <PerpendicularOffset>, posun plochy oproti geometrii (např. pro vytvoření efektu stínu) element <Displacement> [24, s ] PointSymbolizer Element <PointSymbolizer> obsahuje hlavní podřízený element <Graphic>, který je zároveň podřízeným elementem výše zmíněného <GraphicFill>. 38

39 Samotný figurální znak může být vytvořen jedním z předdefinovaných tvarů (kruh, čtverec, trojúhelník, hvězda, kříž nebo symbol x ) v rámci podřízeného elementu <Mark> nebo může být použit externí znak (např. dostupný přes URL v rámci elementu <ExternalGraphics>. V obou případech je možné nastavit průhlednost (element <Opacity>), velikost (element <Size>) a natočení (element <Rotation>) znaku, polohu kotevního bodu (element <AnchorPoint>) a posun znaku (elementem <Displacement>). Posun znaku může být vhodný např. kvůli zamezení konfliktu s jinými znaky nebo kvůli vytvoření znaku složeného z jednodušších tvarů. [24, s ] U externího znaku je barvu možné změnit elementem <ColorReplacement>, u předdefinovaného tvaru je možné nastavit výplň (barvu a texturu) i ohraničení konturou stejně jako u areálového znaku. 39

40 8 PRÁCE S SLD STYLY Z POHLEDU UŽIVATELE 8.1 Vytváření SLD stylu Jak už bylo zmíněno, SLD styl je ukládán ve formátu XML, proto je možné jej vytvářet a editovat v jakémkoliv textovém editoru (např. PSPad). Také je možné styl definovaný v některých desktopových programech exportovat do podoby SLD (viz níže). Tento způsob však vždy nezaručuje věrný a úplný výstup, protože se může lišit přístup k vizualizaci v rámci těchto programů a v rámci SLD specifikace. 8.2 Validace SLD stylu Správnost SLD kódu je možné validovat (např. prostřednictvím volně dostupného online validátoru validome.org) oproti XML schématům (neboli XSD). Jedná se o šablony ve formátu XML, které určují strukturu jiného XML dokumentu. Tedy povolené elementy a jejich atributy, datové typy, hierarchii a pořadí elementů apod. Správnost SLD kódu je možné validovat oproti XML schématu dostupném na adrese: XML schémata SE jsou dostupná zde: Práce s WMS a SLD v programech ArcMap, QGIS a udig Podpora WMS a SLD a možnosti nastavení parametrů se z pohledu uživatele liší u různých klientů. Pro ilustraci byly srovnány tři desktopové programy ArcMap, QGIS a u DIG ArcMap Uživatelské rozhraní programu ArcMap dovoluje zobrazení hodnot atributů daného objektu (požadavek GetFeatureInfo), přes vlastnosti připojené vrstvy nebo skupiny vrstev zobrazení legendy dané vrstvy (požadavek GetLegendGraphic), výběr ze serverem nabízených stylů (parametr STYLES požadavku GetMap), nastavení barvy pozadí (parametr BGCOLOR ), průhledného pozadí (parametr TRANSPARENT ) a grafického formátu zaslané vrstvy (parametr FORMAT ). Nedovoluje však připojení uživatelského 40

41 stylu. Nedovoluje ani konverzi vizualizace z daného projektu do formátu SLD. K tomuto účelu mohou posloužit samostatné nástroje jako je extenze pro ArcGIS GeoCat Bridge společnosti GeoCat [25], program Arc2Earth [26], příp. program ArcMap2SLD [27], který je ale kompatibilní pouze s verzí ArcMap 10.0, ne novější QGIS Uživatelské rozhraní programu QGIS obsahuje méně možností interaktivního zaslání požadavků a nastavení parametrů požadavku GetMap (umožňuje požadavek GetFeatureInfo a nastavení parametru FORMAT požadavku GetMap). Umožňuje ale připojení vlastního uživatelského stylu a to přes nastavení parametrů nového WMS spojení, kde je třeba do pole URL zadat minimálně umístění WMS služby a parametr SLD nebo SLD_BODY požadavku GetMap (ostatní povinné parametry budou doplněny automaticky) a zaškrtnout pole Ignore GetMap/GetTile URI reported in capabilities - v opačném případě by hodnota zadaná v poli URL nebyla brána v potaz a byl by použit předdefinovaný styl. Nastavení je viditelné na obr. 4, výsledek pak na pozadí obrázku. Obr. 4: Ukázka připojení uživatelského stylu k požadavku GetMap přes klienta QGIS Program také dovoluje převod vizualizace dané vrstvy v prostředí QGIS do formátu SLD (přes nabídku Vlastnosti dané vrstvy a nabídku Uložit styl viz obr. 5). Obdobným způsobem lze předem připravený SLD styl do programu načíst a přiřadit k odpovídající vrstvě. 41

42 Obr. 5: Ukázka způsobu exportu vizualizace v prostředí QGIS do formátu SLD udig Program udig je jednoduchý desktopový open source pod licencemi EPL [28] a BSD [29], který ve velké míře podporuje standardy OGC. Nevýhodou programu je oproti předchozím dvěma programům znatelně pomalejší odezva při vykreslování WMS vrstev, ale i vrstev uložených na disku. A také mnohem méně podrobný uživatelský manuál a minimální hlášení chyb, což začínajícímu uživateli ztěžuje práci (např. pokud součástí vrstvy ve formátu shapefile není soubor.prj 16 obsahující popis souřadnicového systému vrstvy, vrstva není vykreslena vůbec a uživatel není upozorněn na důvod). Program také nezobrazuje odezvu na požadavek GetFeatureInfo (u testovaných vrstev), přestože je tato možnost uvedena v uživatelském manuálu [30]. Legendu zobrazuje pouze u menšího počtu testovaných WMS vrstev než program ArcMap. Program umožňuje výběr ze serverem nabízených stylů, nastavení barvy pozadí a grafického formátu zaslané vrstvy. Vizualizace objektů v programu udig je založená na přímo na specifikaci Symbology Encoding, proto autorka tento program hodnotí z dostupných programů jako nejvhodnější pro vytváření SLD stylů. Parametry vzhledu objektů, včetně používání filtrů, jsou téměř totožné jako ve zmíněné specifikaci (viz obr. 6) a proto i výsledný zápis stylu ve formátu SLD nejlépe odpovídá stylu objektů zobrazených v mapovém okně programu. Program v nabídce Style Editor umožňuje zobrazení aktuálního stylu ve formátu SLD (pod záložkou 16 Soubor.prj lze vytvořit např. v prostředí ArcMap (přiřazením souřadnicového systému nástrojem Define Projection) nebo stáhnout ze stránek Spatial Reference [26]. 42

43 XML - obr. 6) a také import a export stylu v SLD. V poslední verzi programu udig RC1 je však stále podporována pouze verze SE/SLD Obr. 6: Ukázka nabídky Style Editor v prostředí programu udig (na příkladu polygonové vrstvy) 43

44 9 PROBLEMATICKÉ ASPEKTY SLD STYLŮ Symbology Encoding umožňuje pouze jednodušší použití areálových, čárových a figurálních znaků. Možnosti tvorby tematických map jsou značně omezené. Symbology Encoding neumožňuje např. jednoduché vytvoření šrafury, používání proporcionálních symbolů, efektivní tvorbu kartogramů, tvorbu kartodiagramů 17. V některých případech je i poměrně jednoduché znaky nutné vytvářet skládáním např. čárový znak s konturou je třeba vytvořit složením dvou samostatných čárových znaků odlišné šířky tak, aby užší linie částečně překrývala širší linii. Dalším problémem jsou aspekty, které způsobují odlišné vykreslování vrstev různým uživatelům, což je v protikladu k myšlence výchozích stylů, které mají vykreslování vrstev sjednocovat. Problémy dotýkající se této práce, jsou popsány v následujících kapitolách. 9.1 Problémy definování velikosti objektů Definování velikostí v pixelech a metrech Prostřednictvím atributu uom lze v elementu každého symbolizéru nastavit používané jednotky velikostí. Ty jsou používány pro vyjádření šířky čárových znaků, šířky kontur areálových znaků, velikost figurálních znaků a dalších vlastností. Implicitně jsou používány pixely tedy bezrozměrné jednotky vztažené k zobrazovacímu zařízení, je však možné nastavit také metry nebo stopy vztažené ke vzdálenostem na Zemi [24, s ]. Není však možné nastavit reálnou absolutní velikost znaku zobrazeného uživateli. Použití jednotek může mít výrazný vliv na výsledný vzhled zobrazovaných dat a grafickou zaplněnost mapy 18. Při definování velikosti v pixelech se absolutní velikost znaku (např. šířka linie) nemění v závislosti na použitém měřítku, ale při přibližování a oddalování mapy zůstává konstantní. Naopak při definování velikosti např. v metrech se absolutní velikost znaku výrazně mění - čím menší je použité měřítko, tím menší jsou i absolutní velikosti zobrazených objektů. Srovnání obou přístupů je ukázáno na obr. 7 až obr. 12, kde je znázorněna silniční síť ze sady objektů ZABAGED. Na obr. 7, obr. 9 a obr. 11 je šířka zelené linie vždy 3 pixely a šířka spodní černé linie vždy 7 pixelů (styl odpovídá pokynům v datové specifikaci). Na obr. 8, obr. 10 a obr. 12 je šířka zelené linie vždy 8 metrů a šířka spodní černé linie vždy 17 Možnostmi rozšíření specifikace SE (především o kartodiagramy a kartogramy) se zabývá např. [54] a lidé z University of Zurich např. [56]. Specifikace OGC však o tyto možnosti rozšířena nebyla. 18 Grafická zaplněnost odpovídá poměru plochy pokryté kresbou a popisem k celkové ploše mapy, která by neměla překročit hodnotu 30% [53]. 44

45 18,5 metrů. Obrázky 1 a 2 vypadají identicky, protože při měřítku 1 : a rozlišení 96 DPI je výsledná šířka mapového znaku téměř totožná (zelená linie cca 0,79 mm a černá linie cca 1,85 mm). Při změně měřítka (obr. 3 6) se projeví rozdíly. Pro dostatečnou názornost obrázků byly zvoleny dostatečně kontrastní měřítka (1 : , 1 : , 1 : ). 45

46 Obr. 7: Zobrazení silniční sítě se šířkou čárových znaků definovanou v pixelech - v měřítku 1 : , zdroj dat: [31] Obr. 8: Zobrazení silniční sítě se šířkou čárových znaků definovanou v metrech - v měřítku 1 : , zdroj dat: [31] 46

47 Obr. 9: Zobrazení silniční sítě se šířkou čárových znaků definovanou v pixelech - v měřítku 1 : , zdroj dat: [31] Obr. 10: Zobrazení silniční sítě se šířkou čárových znaků definovanou v metrech - v měřítku 1 : , zdroj dat: [31] 47

48 Obr. 11: Zobrazení silniční sítě se šířkou čárových znaků definovanou v pixelech - v měřítku 1 : , zdroj dat: [31] Obr. 12: Zobrazení silniční sítě se šířkou čárových znaků definovanou v metrech - v měřítku 1 : , zdroj dat: [31] 48

49 Z hlediska znázorňování polohopisu fyzických objektů je pro uživatele přirozenější chování mapové služby s jednotkami v metrech, protože vykreslování dat zachovává pravidla perspektivy čím jsou objekty vzdálenější, tím se jeví menší. Zachovává také proporcionalitu ploch v mapě (vzdálenost volné plochy mezi dvěma silnicemi je v poměru k šířce těchto silnic konstantní). A tím pádem také zachovává konstantní grafickou zaplněnost mapového pole. Velikosti mapových znaků navíc nejsou ovlivněny rozdíly v rozlišení zobrazovacích zařízení uživatelů (viz následující kapitola). Naopak pokud samotná velikost znaku nese tematickou informaci (např. šířka čárového znaku pro silnici vyjadřuje významnost této komunikace, její typ nebo počet jízdních pruhů), pak je vhodné zachovávat velikost konstantní, aby nedocházelo k chybné interpretaci a zobrazení znaků na mapě bylo v souladu s legendou. Další nevýhodou definování velikosti mapových znaků v metrech je fakt, že mapové znaky, které jsou vhodné pro větší měřítka, se po oddálení mapy mohou zobrazovat už tak malé, že jsou špatně viditelné a odlišitelné od jiných znaků. Použití atributu uom je také umožněno až od aktuální verze specifikace Symbology Encoding, některé servery jej tedy stále nemusí podporovat (např. Geoserver nebo program udig atribut podporují). V praxi je tedy pro zobrazování mapové služby v širokém rozsahu možných měřítek obvykle vhodnější definování velikostí v pixelech a to odlišně pro několik intervalů měřítek v souladu s celkovou koncepcí kartografické symboliky (podobně jako se liší znakové sady pro jednotlivá měřítka u rozdílných měřítkových řad tištěných kartografických produktů). Negativní aspekty definování velikosti v pixelech nebudou v rámci užšího měřítkového intervalu tolik výrazné. Definování velikostí v metrech má smysl spíše u největší měřítek (u zvolených ukázek např. do měřítka 1 : ), tak aby u těchto měřítek byla zachována proporcionalita a perspektiva (příp. aby plocha, kterou zaujímá čárový znak, odpovídala ploše, kterou objekt zabírá ve skutečnosti), a od daného měřítka se velikosti znaků při oddalování mapy zmenšovaly skokově (dle předchozího odstavce). Nejvhodnější řešení u konkrétního stylu závisí na více faktorech, jako je jeho účel nebo kombinování s dalšími vrstvami, což je však v rámci směrnice INSPIRE a souvisejících dokumentů definováno jen velmi obecně Rozdíly v rozlišení zobrazovacích zařízení Při definování velikosti v pixelech je významným faktorem, který má vliv na výslednou velikost mapových znaků, rozlišení zobrazovacích zařízení jednotlivých uživatelů (v DPI 19 ). Čím větší je rozlišení (DPI) zobrazovacího zařízení, tím menší je absolutní velikost jednoho pixelu a tím menší se tedy také zobrazuje daný mapový znak 19 Hodnota DPI (Dots per inch) udává množství zobrazených bodů na délku jednoho palce (tedy 2,54 cm). Někdy se hodnotou DPI označuje pouze hustota tiskových bodů a hustota obrazových bodů (pixelů displeje) bývá označována jako PPI (Pixels per inch). V této práci se tyto pojmy nerozlišují. 49

50 a naopak. Poskytovatel tedy nemůže kontrolovat reálnou velikost zobrazení mapových znaků a tudíž ani grafickou zaplněnost zobrazené mapy. Rozdíly jsou znatelné hlavně při exportech nebo tisku mapových vrstev, kdy uživatelé často zadávají velmi rozdílná rozlišení. Srovnání je patrné z obr. 13 až obr. 15. Řešením je buď upozornění uživatele na doporučené rozlišení, ve kterém je vrstva optimálně vyvážená a koresponduje s legendou, nebo poskytování služby se zdrojovými daty v rastrovém formátu s pevně danou velikostí mapových znaků v poměru k celému výřezu mapy. Tedy buď ve formě WMS nebo WMTS. Tím už se však zase ztrácí možnosti využití a výhody SLD stylů. V rámci této práce jsou u vlastních návrhů vizualizace ve formě SLD stylů (viz kap. 11) používány jednotky pixelů (stejně jako je tomu v datových specifikacích, pokud je SLD styl uvedený) a velikost znaků je optimalizována pro rozlišení 91 DPI, dle doporučení ve specifikacích OGC [24, s. 9]. Obr. 13: Zobrazení silniční sítě v měřítku 1 : v rozlišení 91 DPI 20, zdroj dat: [32] 20 Obr. 7 a obr. 13 mají velmi podobné parametry, přesto jsou patrné rozdíly v hrubosti vykreslení šikmých hran. Obr. 7 je zobrazen v programu udig, kde je možné použití vlastního stylu ve formátu SLD (více viz kap ). Obr. 13 je exportován z programu ArcMap, který zase umožňuje export v různém rozlišení. Rozdíly jsou tedy způsobeny odlišným chováním obou programů - v programu udig je nastaven antialiasing (způsobuje vyhlazení hran). 50

51 Obr. 14: Zobrazení silniční sítě v měřítku 1 : v rozlišení 150 DPI, zdroj dat: [32] Obr. 15: Zobrazení silniční sítě v měřítku 1 : v rozlišení 300 DPI, zdroj dat: [32] 51

52 9.2 Problémy měřítkových omezení Pokud chce poskytovatel dat zabránit tomu, aby se uživateli na obvyklých monitorech zobrazovala mapa příliš graficky zaplněná (viz obr. 11), může zobrazení konkrétní vrstvy omezit pouze na interval určitých měřítek. Existují v podstatě dva přístupy k měřítkovým omezením. Buď je ze strany poskytovatele uživateli pouze oznámeno doporučené měřítko nebo měřítkový rozsah pro danou vrstvu, nebo jsou měřítková omezení ze strany poskytovatele pevně dána. Případně je možné oba přístupy kombinovat. První varianta poskytuje uživateli větší volnost, ale zase je pro něj méně pohodlná - pokud pracuje s více vrstvami a chce dosáhnout ideálního zobrazování vrstev, je nucen během přibližování a oddalování mapy jednotlivé vrstvy průběžně vypínat a zapínat. Pro účely informování uživatele slouží informace v elementech <MinScaleDenominator> a <MaxScaleDenominator> zobrazená ke každé vrstvě jako odpověď na požadavek GetCapabilities (viz obr. 16). Obr. 16: Ukázka části odezvy na požadavek GetCapabilities WMS služby INSPIRE prohlížecí služba pro téma Dopravní sítě (TN) poskytované ZÚ Poskytovatel může měřítková omezení pevně nastavit buď pro samotnou vrstvu (nastavením mapového serveru) nebo pouze pro daný styl - prostřednictvím pravidla v rámci dříve zmíněného elementu <Rule> (viz kap. 7.1). Pokud je účelem měřítkových omezení zabránit nevhodnému vykreslení vrstvy s daným stylem, pak je logičtější a 52

53 uživatelsky přívětivější omezení právě v rámci tohoto stylu a ne vrstvy samotné. Obvyklá praxe je však spíš opačná. Měřítková omezení pomocí pravidel <Rule> se zapisují prostřednictvím podřízených elementů s totožnými názvy jako v GetCapabilities: <MinScaleDenominator> a <MaxScaleDenominator. Hodnota měřítka je zadávána ve formě měřítkového čísla buď ve standardním zápise (např ) nebo vědeckou notací (10e6). Hodnota elementu <MinScaleDenominator> je vyhodnocována tak, že uvedené číslo již spadá do intervalu (odpovídá zleva uzavřenému intervalu), naopak hodnota elementu <MaxScaleDenominator> už do intervalu nespadá (zprava otevřený interval). [15, s ] Při omezení zobrazení vrstev v závislosti na měřítku však vlivem rozdílů ve velikosti pixelu výstupních zařízení a také v důsledku rozdílného přepočtu úhlových jednotek na jednotky lineární dochází k problémům popsaných v následujících kapitolách. Měřítková omezení se totiž aplikují v různých situacích odlišně, což je pro neinformovaného uživatele těžko předvídatelné a matoucí Rozdíly ve velikosti pixelu výstupních zařízení V OGC specifikacích je standardizovaná velikost pixelu definována na 0,28 mm x 0,28 mm [15, s. 27], [24, s. 9] (což odpovídá přibližně 90,71 DPI, pro zjednodušení dále uvažujme 91). Skutečné rozlišení se však na různých výstupních zařízeních uživatelů může lišit a tato hodnota je pro server neznámá. To způsobuje nesprávnou interpretaci měřítkových omezení. Pokud tedy klient zašle serveru požadavek GetMap s uvedenými souřadnicemi požadovaného výřezu a informaci, do kolika pixelů má být obraz rozdělen, server na základě tohoto a předpokládané velikosti pixelu 0,28 mm určí předpokládané měřítko mapové vrstvy. Na základě srovnání tohoto měřítka s nastaveným měřítkovým omezením dané vrstvy (stylu), buď požadovanou vrstvu klientovi zašle, nebo nezašle. Předpokládejme, že povolený měřítkový rozsah je <50 000; ) a uživatel tuto informaci zná z GetCapabilities díky elementům: <MinScaleDenominator>50000</MinScaleDenominator> <MaxScaleDenominator>100000</MaxScaleDenominator> I v případě, že je skutečné rozlišení výstupního zařízení např. 70 DPI (což znamená větší velikost pixelu), server stále předpokládá standardní rozlišení 90,71 DPI. Zaslané mapové vrstvy se tedy zobrazují roztaženější a jejich reálné měřítko je větší (měřítkové číslo je menší), než server předpokládá. Uživatel tedy může mít ve svém klientu nastavené 53

54 měřítko (označujme toto měřítko jako reálné, byť to není zcela přesné viz dále), které je < a uživatel tedy očekává bezproblémové zobrazení vrstvy, ale server tuto vrstvu vyhodnocuje v měřítku a zašle tedy prázdnou vrstvu. To může být pro uživatele značně matoucí. A naopak, pokud je skutečné rozlišení výstupního zařízení např. 300 DPI (typicky při tisku nebo exportu vrstvy), což odpovídá menší velikosti pixelu než 0,28 mm, reálné měřítko mapy je menší, než server předpokládá. Pokud je reálné měřítkové číslo , ale server jej předpokládá < , pak opět nedojde k vykreslení vrstvy, kterou uživatel očekává. Dochází tedy k nesouladu chování serveru a doporučeními uvedenými v odezvě GetCapabilities. Analogicky server může zaslat i mapovou vrstvu, kterou by při znalosti reálného měřítka už zaslat neměl, což ovšem takový problém není. Obvyklé GIS softwary jako třeba ArcMap [33], QGIS nebo udig pracují s rozlišením 96 DPI (oproti tomu např. Open Layers předpokládá rozlišení 72 DPI). Jsou laděny právě na toto rozlišení monitoru a dle tohoto předpokladu uživateli zobrazují číselné měřítko daného náhledu mapy 21. Posun oproti standardu tedy není příliš velký. Pokud ale uživatel nastaví měřítko blízké okrajům intervalu, rozdíl se stejně projeví. Reálné měřítko 1 : zobrazené v programu ArcMap (který uvažuje rozlišení 96 DPI, tedy velikost pixelu cca 0,265 mm) je na straně serveru (řídí-li se specifikací a předpokládá velikost pixelu 0,28 mm, tedy cca 90,71 DPI) považováno za měřítko přibližně 1 : Nejvíce je rozdíl patrný při exportu nebo tisku mapových vrstev, kdy uživatel přímo určuje požadované rozlišení v dpi a rozdíly oproti specifikaci mohou být mnohem znatelnější. Některé servery řeší předání informace o rozlišení vlastními doplňkovými parametry. U Geoserveru lze použít pro informování serveru o rozlišení 300 dpi v požadavku GetMap parametr FORMAT_OPTIONS=dpi:300, u MapServeru parametr MAP_RESOLUTION =300, u QGIS serveru DPI=300. Desktopový program QGIS všechny výše uvedené parametry automaticky přidává do požadavku GetMap, který zasílá serveru (vypnout nebo 21 Proto také při práci v těchto softwarech a obrazovkou v jiném rozlišení než 96 dpi číselné měřítko ve skutečnosti neodpovídá mapě zobrazené na monitoru. 54

55 zvolit pouze jeden z těchto parametrů je možné nastavením volby v rozbalovacím menu DPI-Mode při nastavení parametrů nového WMS spojení). Specifikace Symbology Encoding [24, s. 9] uvádí jako možné řešení problému překreslení výsledného obrazu klientem tak, aby měřítko mapy zobrazené uživateli odpovídalo měřítku, které předpokládá server. Ve specifikaci je však uveden chybný vzorec pro výpočet tohoto měřítka vztah mezi absolutní velikostí pixelu a měřítkovým číslem je nepřímou úměrou, ale vzorec je zapsán, jakoby šlo o přímou úměru Rozdíly v přepočtu úhlových jednotek na lineární Druhým problémem je nekonzistence mezi různými způsoby výpočtu měřítka uživatelských klientů a serveru vzhledem k souřadnicovému systému. V SE specifikaci [24, s. 10] je popsán zjednodušující výpočet měřítka vzhledem k souřadnicovému systému. U souřadnicových systémů používajících úhlové jednotky 22 je doporučen přepočet na lineární jednotky (pro určení měřítkového čísla) na základě obvodu Země na rovníku (uvažovaný poloměr Země je m). Např. pokud má zobrazená oblast rozsah 2 (vypočteno z rozdílu souřadnic v BBOXu) v souřadnicovém systému WGS-1984, pak je lineární délka tohoto úseku vypočtená takto: z čehož je při požadavku vykreslení úseku např. do 600 px a velikosti pixelu 0,28 mm vypočteno měřítkové číslo ,19: Hlavně ve vyšších zeměpisných šířkách tedy opět dochází k rozdílu v měřítku, které předpokládá server a klient a tím k matoucímu uplatňování měřítkových omezení. Při požadavku na zaslání mapy vždy ve stejném měřítku (z pohledu nastavení klienta) se situace, kdy od serveru mapu obdržím a kdy ne, může lišit jen na základě zvoleného souřadnicového systému nebo posunu požadovaného mapového výřezu. Geoserver nabízí vlastní volitelný parametr ScaleMethod, který nabývá hodnot OGC (výpočet měřítkového omezení probíhá podle OGC specifikace) nebo Accurate (výpočet probíhá nezávisle na OGC specifikaci - je brán v úvahu zploštělý tvar Země a výpočet je tedy přesnější). [34] 22 Což jsou z doporučených souřadnicových systémů dle INSPIRE pouze souřadnicové systémy označené jako ETRS89-GRS80 (EPSG: 4258) a ETRS89-GRS80h (EPSG: 4937). 55

56 Z obou výše uvedených důvodů (nesrovnalosti dané různým předpokladem rozlišením v DPI a nesrovnalosti dané zjednodušeným výpočtem lineární vzdálenosti ze souřadnic) by bylo vhodné, aby reálný interval měřítek povolených pro danou vrstvu byl širší, než interval doporučený v GetCapabilities. Pokud jsou měřítková omezení použita v rámci jednoho stylu pro odlišení několika způsobů vizualizace pro různé měřítkové intervaly, pak to samozřejmě možné není (docházelo by k překryvům obou způsobů vizualizace). 56

57 10 TÉMA DOPRAVNÍ SÍTĚ Pro podrobnější zhodnocení vizualizace bylo zvoleno téma Dopravní sítě (angl. Transport Networks). Proto jsou také konkrétní příklady v předchozí části práce voleny z tohoto tématu. Toto téma je jedno z nejobsáhlejších a poskytuje dostatek prostoru pro kritické zhodnocení a vlastní návrh úprav. Téma je součástí přílohy I směrnice INSPIRE a dle popisu směrnice do něj spadají Silniční, železniční, letecké a vodní dopravní sítě a související infrastruktura. Zahrnují spojnice mezi jednotlivými sítěmi. Zahrnují rovněž transevropskou dopravní síť vymezenou předpisy Evropského společenství. [4, příl. I] Hodnoty ze společného registru číselníků (viz kap ) v rámci silniční sítě počítají např. i s pěšími stezkami nebo cyklostezkami [35]. Podrobnější popis je uveden v dokumentu Definition of Annex Themes and Scope [6, s ] Struktura dat Jak již bylo zmíněno, struktura dat tématu dopravní sítě vychází z dokumentů Generic Conceptual Model, Generic Network Model a datové specifikace pro téma dopravní sítě. Téma je rozděleno do šesti aplikačních schémat popsaných v datové specifikaci pro dopravní sítě. Jsou to: společné prvky dopravní infrastruktury, silniční dopravní síť, dopravní síť kolejové dráhy, síť vodní dopravy, letecká dopravní síť, síť lanové dopravy. Třídy z aplikačních schémat jednotlivých druhů dopravy jsou hierarchicky pod třídami z aplikačního schématu společných prvků dopravní infrastruktury, které jsou zase podřízené třídám z aplikačního schématu Sítě (angl. Network), popsaném v dokumentech Generic Conceptual Model a Generic Network Model. Téma je přes některé třídy také provázáno s tématy Zeměpisné názvy, Adresy a Vodopis. V tab. 5 je uveden seznam vrstev, které mají být poskytovány prostřednictvím mapových služeb, a typů objektů, které jsou obsahem těchto vrstev dle Nařízení o interoperabilitě [14, příl. II]. Černou barvou jsou v tabulce označeny závazné názvy uváděné v angličtině, červenou barvou jsou pro lepší orientaci v tabulce uvedeny české ekvivalenty dle českého překladu nařízení. 57

58 Tab. 5: Seznam vrstev a typů objektů, které mají být poskytovány členskými státy aplikační schéma typ vrstvy typ objektů Common Transport Elements Společné prvky dopravní infrastruktury Road Transport Network Silniční dopravní síť Railway Transport Network Dopravní síť kolejové dráhy Water Transport Network Síť vodní dopravy Air Transport Network Letecká dopravní síť Cable Transport Network Síť lanové dopravy TN.CommonTransportElements.TransportNode TN.CommonTransportElements.TransportLink TN.CommonTransportElements.TransportArea TN.RoadTransportNetwork.RoadLink TN.RoadTransportNetwork.VehicleTrafficArea TN.RoadTransportNetwork.RoadServiceArea TN.RoadTransportNetwork.RoadArea TN.RailTransportNetwork.RailwayLink TN.RailTransportNetwork.RailwayStationArea TN.RailTransportNetwork.RailwayYardArea TN.RailTransportNetwork.RailwayArea TN.WaterTransportNetwork.WaterwayLink TN.WaterTransportNetwork.FairwayArea TN.WaterTransportNetwork.PortArea TN.AirTransportNetwork.AirLink TN.AirTransportNetwork.AerodromeArea TN.AirTransportNetwork.RunwayArea TN.AirTransportNetwork.AirspaceArea TN.AirTransportNetwork.ApronArea TN.AirTransportNetwork.TaxiwayArea TN.CableTransportNetwork.CablewayLink TransportNode Dopravní uzel TransportLink dopravní spojnice TransportArea Oblast dopravní infrastruktury RoadLink Silniční spojnice VehicleTrafficArea Oblast provozu vozidel RoadServiceArea Oblast silniční služby RoadArea Koruna silnice RailwayLink Spojnice kolejové dráhy RailwayStationArea Oblast stanice kolejové dráhy RailwayYardArea Oblast nákladní kolejové skupiny RailwayArea Oblast kolejové dráhy WaterwayLink Spojnice vodní cesty FairwayArea Oblast plavební dráhy PortArea Oblast přístavu AirLink Letecké spojení AerodromaArea Oblast letiště RunwayArea Oblast dráhy AirspaceArea Oblast vzdušného prostoru ApronArea Oblast odbavovací plochy TaxiwayArea Oblast pojezdové dráhy CablewayLink Spojnice lanové dráhy 58

59 10.2 Geometrická reprezentace dat Datová specifikace [36, s. VII, 18] počítá se třemi možnými typy geometrie plošnou, liniovou a bodovou. Zároveň je povolena vícenásobná reprezentace stejných objektů, což je výhodné kvůli možné odlišné úrovni podrobnosti dat. Je umožněna plošná reprezentace (vytvořená na základě podrobného mapování) a alternativně k ní liniová reprezentace (vytvořená zobecněním objektu na jeho středovou linii). Proto je také např. pro silnici definován typ objektu RoadLink (středová linie neboli spojnice silnice) a RoadArea (celá plocha povrchu silnice). Obdobně je pro železniční dráhu definován typ objektu RailwayLink (spojnice dráhy) i RailwayArea (plocha neboli oblast dráhy) a pro plavební cestu je definován typ objektu WaterwayLink i FairwayArea Dostupnost dat za Českou republiku V rámci České republiky téma Dopravní sítě spravuje Zeměměřický úřad (ZÚ), který je pro toto téma povinným poskytovatelem [37, s. 7]. Ze strany ZÚ jsou prostřednictvím mapových služeb poskytovány objekty, které odpovídají datové specifikaci a zároveň jsou zahrnuty ve zdrojové sadě ZABAGED. Pouze k objektu RoadLink nejsou přiřazeny objekty Pěšina (s pořadovým číslem 2.04 z katalogu objektů ZABAGED), Silnice ve výstavbě (2.32) a Cesta (2.03), pokud má atribut typ cesty hodnotu cesta parková a hřbitovní. Tab. 6 ukazuje vztah objektů definovaných v datové specifikaci a jim odpovídajících objektů ze sady ZABAGED. Objekty jsou ve vztahu 1 : 1 (jednomu typu objektů INSPIRE odpovídá právě jeden typ objektů ze sady ZABAGED), 1 : N (jednomu typu objektů INSPIRE odpovídá více typů objektů ZABAGED), M : 1 (více typům objektů INSPIRE odpovídá pouze jeden typ objektu ZABAGED, ale rozčlenění je možné na základě atributu) i 1 : 0 (pro daný typ objektů INSPIRE neexistuje v rámci sady ZABAGED ekvivalentní typ objektu). U společných prvků dopravní infrastruktury je v tabulce pro lepší orientaci naznačena také hierarchie (zkratka abstr. označuje abstraktní třídu.). Pro některé z dopravních uzlů (TransportNode) neexistují ekvivalentní objekty přímo v rámci sady ZABAGED, ale bylo možné je z existujících objektů odvodit. Zároveň jsou ale mezi dopravní uzly zahrnuty i mimoúrovňové křižovatky, které by být zahrnuty neměly, protože se zde silniční spojnice pouze kříží, ale neprotínají [36, s. 23]. 59

60 Tab. 6: Objekty dle INSPIRE a jim odpovídající objekty datové sady ZABAGED typ objektů INSPIRE typ objektů ZABAGED Silnice, dálnice (2.01) Ulice (2.02) RoadLink Cesta (2.03) Silnice neevidovaná (2.31) VehicleTrafficArea - RoadServiceArea Parkoviště, odpočívka (2.15) RoadArea - RailwayLink Železniční trať úsek (2.17) Železniční vlečka (2.18) Tramvajová dráha (2.24) Metro (2.28) Lanová dráha, lyžařský vlek (2.22) RailwayStationArea Areál železniční stanice, zastávky (2.33) RailwayYardArea Kolejiště (2.19) RailwayArea - WaterwayLink Přívoz (2.13) FairwayArea - PortArea Areál účelové zástavby (1.27) AirLink - AerodromeArea Letiště (2.25) RunwayArea Obvod letištní dráhy (2.26) AirspaceArea - ApronArea - TaxiwayArea Obvod letištní dráhy (2.26) CablewayLink Lanová dráha, lyžařský vlek (2.22) atribut objektů ZABAGED TYPUSKOM_K: PL (pozemní lanová dráha) TYPZAST_K: 402 (přístav) TYPDRAHY_K: PV (přistávací a vzletová) TYPDRAHY_K: PO (pojížděcí) TYPUSKOM_K: V, L (visutá lanová dráha, lyžařský vlek) společné prvky dopravní infrastruktury TransportNode (abstr.) x Křižovatka mimoúrovňová (2.05) RoadNode Křižovatka úrovňová (2.06) Uzlový bod silniční sítě (2.07) ostatní vytvořeno nově RailwayNode vytvořeno nově RailwayYardNode - RailwayStationNode vytvořeno nově CablewayNode - WaterNode (abstr.) x WaterwayNode - PortNode - AirNode - Navaid - DesignatePoint - RunwayCentrelinePoint - 60

61 AerodromeNode vytvořeno nově TouchDownLiftOff Heliport (2.34) TransportLink (abstr.) x TransportArea (abstr.) x Od července 2013 jsou data zpřístupněna prostřednictvím prohlížecích služeb (WMS), od srpna 2014 i prostřednictvím stahovacích služeb (WFS). Dle [38] jsou dostupné služby v souladu s datovou specifikací tématu dopravní sítě (verze 3.0.1) i Technickým návodem pro prohlížecí služby (verze 3.11). WMS služby jsou zpřístupněny zdarma, WFS služby jsou zpoplatněny (ceny se pohybují od 0 do 5,7 Kč/km 2, výdejní jednotkou je BBOX vybraného území, případně administrativní celek). [39, s. 32] 61

62 10.4 Výchozí styly dle datové specifikace Kartografická vizualizace tématu dopravní sítě je v rámci kapitoly Portrayal dané datové specifikaci [36, s ] popsána slovně a neúplným SLD zápisem. Na obr. 17 jsou zobrazeny mapové znaky vytvořené na základě tohoto popisu (procenta udávají opacitu výplně daného znaku, která u znaků na obrázku není zahrnuta na světlém pozadí by se tedy barvy jevily světlejší). Obr. 17: Kartografická vizualizace objektů tématu Dopravní sítě 62

63 Většina zemí Evropské unie poskytuje pouze neharmonizované WMS služby tématu dopravních sítí - s vlastní strukturou dat i způsobem vizualizace. Česká republika, Slovensko, Polsko, Estonsko a Lucembursko (výčet nemusí být úplný) poskytují vrstvy s výchozím stylem inspire_common:default, který do velké míry odpovídá pokynům ve specifikaci. Polsko poskytuje některé vrstvy silniční, železniční vodní i lanové dopravy [40]. Oproti specifikaci je vrstva Road Link zobrazena černou, silnější linií (což může být dáno špatným pořadím linie a její kontury), vrstva Cableway Link je zobrazena bez kontury. Estonsko poskytuje vrstvy Road Link, Road Area, Railway Link [41] a všechny vrstvy letecké dopravní sítě [42]. Oproti specifikaci jsou čárové znaky zobrazovány bez kontur (případ vrstvy Road Link a Air Link). Lucembursko poskytuje vrstvy Road Link, Railway Link a Cableway Link [43]. Oproti specifikaci jsou čárové znaky opět zobrazovány bez kontur, Cableway Link je zobrazena v trochu odlišném odstínu. Za Slovensko poskytuje WMS jednak Úrad geodézie, kartografie a katastra Slovenskej republiky (ÚGKK) a také Slovenská správa ciest. Slovenská správa ciest poskytuje pouze vrstvu Road Link (bez kontury) a Generic Transport Node [44], ÚGKK několik vrstev k silniční, železniční i letecké dopravě (čárové znaky jsou zobrazeny širší, než udává specifikace a navíc rozdělené na jednotlivé úseky, vrstva Transport Node obsahuje pouze body podél lanové dráhy, což je chybnou) [45] Vizualizace vrstev WMS služeb poskytovaných za Českou republiku Vrstvy dostupné prostřednictvím WMS služby Zeměměřický úřad poskytuje s odpovídajícím výchozím stylem dle datové specifikace, čímž výrazně převyšuje evropský standard. Většina kontur čárových znaků nebo areálových znaků je zobrazena o 1-2 pixely širších, než udává specifikace. Rozdíl je dán, tím, že ZÚ nepoužívá SLD styly ve formátu XML, vizualizace je vytvářena přímo v softwaru Geomedia. V praxi je ale odchylka téměř nepatrná. Rozdíl je možné posoudit např. při srovnání vrstvy Road Link (Silniční spojnice) s ponechaným defaultním stylem poskytnutým Zeměměřickým úřadem a stejné vrstvy s přiřazeným uživatelským SLD stylem vytvořeným podle specifikace (viz tab. 7). 63

64 náhled při zvětšení požadavek Tab. 7: Srovnání (pomocí předchystaného požadavku nebo zobrazeného detailu) vrstvy Road Link zobrazené s defaultním stylem ZÚ a stylem dle datové specifikace výchozí styl ZÚ TN/WMService.aspx?SERVICE=WMS& VERSION=1.3.0&REQUEST=GetMap& Layers=Road_Link&CRS=EPSG:3035&B BOX= , , , &WIDTH=43 9&HEIGHT=284&FORMAT=image/png &SLD= výchozí styl vytvořený dle specifikace N/WMService.aspx?SERVICE=WMS&VE RSION=1.3.0&REQUEST=GetMap&Layer s=road_link&crs=epsg:3035&bbox= , , , &WIDTH=439&HEIG HT=284&FORMAT=image/png&STYLES =default V případě vrstvy Runway Area (Oblast dráhy) jsou objekty zobrazeny světlým odstínem šedé místo bílé barvy (v hexadecimálním zápisu RGB #FAFAFA místo #FFFFFF). Nepoužití čistě bílé barvy může být výhodné kvůli programům, které u WMS vrstev automaticky převádí bílé pozadí na průhledné. 64